Assign people to a pull request from its summary tab

[TonybynMp4]

The Pull Requests summary tab shows reviewers but not assignees, and T3 Code has no way to assign anyone. To hand a PR to a teammate, or take it yourself, you have to leave for GitHub or GitLab.

Proposal

Add an Assignees row to the summary tab, with a menu to add and remove people. It would work on GitHub and GitLab.

• Only accounts with triage access on the repository get the menu, since the host rejects the change from anyone else.
• People already assigned are listed first, read from the PR itself. GitLab's users endpoint returns one page of 100, so without this an assignee past that page could not be removed.
• When the first page isn't everyone, typing in the menu also searches the host (assignableUsers(query:) on GitHub, users?search= on GitLab).
• Like GitLab's own assignee dropdown, picks are saved once the menu closes, as one change. That lets the menu respect the host's limit before anything is sent.

Assignee limits

Each host caps how many people can be assigned, and the menu follows the cap:

• GitHub keeps up to 10. Once 10 are picked, the others are disabled and the menu says why.
• GitLab Free keeps one, and silently drops the rest if sent more. GitLab's GraphQL reports this per merge request (allowsMultipleAssignees), so the row reads "Assignee" and picking someone replaces the current one, as GitLab's UI does.
• Paid GitLab allows up to 200 (Issuable::MAX_NUMBER_OF_ASSIGNEES_OR_REVIEWERS).

The server refuses a list over the limit too, so the host never quietly keeps only part of it. An older GitLab that can't answer the query falls back to no limit in the menu, and the host stays the final check.

Out of scope

• Mobile, which has no PR summary tab yet.
• MCP tools for agents to read or set assignees. Today they'd use gh or glab. Happy to add this as a follow-up.
• The reviewer menu has the same first-page limit and the same one-reviewer rule on GitLab Free (allowsMultipleReviewers). That's a separate fix.
• The label and reviewer menus still save on each click. Moving them to save-on-close would be a follow-up, if wanted.

Already built

I implemented this in #22381, which was closed for lacking prior approval. The first version was tested by hand against GitHub and a self-hosted GitLab instance. The limits and save-on-close are covered by unit tests for both hosts so far. I don't have a paid GitLab to assign on, so that path is checked only by reading the flag from gitlab.com. Names and titles are blurred below because the GitLab instance is internal. The screenshots predate the save-on-close change, which doesn't change how the menu looks.

Before	After

Assign menu, current assignee first:

Typing in the menu also asks GitLab, which finds someone past the first page of 100:

The same PR also adds filtering by assignee, which I've proposed separately in #14336 (comment). The PR can be split in 2 and ship separately.

If the direction and scope work, I'll resubmit the assign part on its own.