Assignable Colleagues

The ticket detail assignee picker's roster -- deliberately a DIFFERENT list than GET /tickets/owners above (the Owner FILTER), and a different query than that route's handler runs. See supervisor_service.list_assignable_colleagues and its module's "Owner filter" section header for why: that route only ever lists people who already own a visible ticket, which is a deadlock for the first assignment to any colleague (the exact bug Frederick hit live on staging, 2026-07-30) -- this route lists every active human, whether or not they own anything yet.

Registered BEFORE /tickets/{ticket_id} for the same routing reason /tickets/owners and /tickets/counts are above.

Gated the SAME way as /tickets/owners and /tickets/counts -- at least one of tickets:b2c/tickets:b2g, via _allowed_kinds -- deliberately NOT admin:people:read (GET /api/platform/principals's gate). A CS agent reassigning a ticket to a teammate has no reason to hold the admin People-tab grant, and requiring it would 403 the exact person this picker is for. Unlike /tickets/owners, the returned roster itself is NOT further scoped to kinds -- see supervisor_service.list_assignable_colleagues's docstring for why a broad, all-active-humans list is the correct one here. The caller still needs a real CS grant to reach this route at all; PATCH /tickets/{id}/assignee still requires the per-ticket-kind grant to perform the assignment (_require_kind_grant, unchanged) -- this route only widens who may APPEAR as a target, never who may act.