[HTExplicit]

Problem

On the account page, "apply to all filtered results" ignored the selected group.

• This fork reads the account list's group filter as group_id (upstream calls it group), and the page sends group_id in the filters of bulk-by-filter requests too.
• BulkUpdateAccountFilters only bound group, so the value was dropped when the targets were resolved.
• POST /admin/accounts/bulk-update then changed more accounts than the list showed. With only a group selected, the filter object was empty for the server and the edit applied to every account.
• POST /admin/accounts/bulk-taxonomy resolved the same wider set and failed its expected_match_count check.

Found on 2026-10-04 while mapping the account search for #239.

Change

• BulkUpdateAccountFilters binds group_id next to group.
• bulkAccountFilterGroup picks the request's group: group_id, or group when group_id is empty. Two different values are rejected with 400 INVALID_GROUP_FILTER rather than one being picked, since this filter decides which accounts a bulk operation changes.
• toServiceBulkUpdateAccountFilters uses that one value for both filter shapes (scalar and console). Bulk update and bulk taxonomy share the resolver, so both are fixed.

Backend only. The page already sends group_id. Callers that send group behave as before.

Verification

• gofmt, go build ./internal/handler/....
• New TestBulkUpdateFilterTargetResolvesWithinTheGroupFilter: posts real bulk requests and asserts the group passed to the target-resolving list call, for both filter shapes, ungrouped, group_id alone, the older name, both names agreeing, and no group; and that disagreeing or invalid values return 400 without resolving a target or creating a job. With the group_id binding removed, 8 of its 12 subtests fail.
• The existing bulk filter, job scope and selection guard tests in the package still pass.
• One review pass over every consumer of the filter and over the tests, each finding checked by a second reader: no confirmed defect.

Known, unchanged: in the scalar filter shape an invalid group value (abc, a negative number) is still handled as it was for group (the page cannot send such values); GET /admin/accounts/upstream-billing-rates still reads group and does not receive the page's multi-value filters.

Not run: full suites, integration tests (no data-layer change), real model calls.

🤖 Generated with Claude Code