Reviewer/assignee actor-mode asymmetry

Leaving a note here for future context since this came up during review.

When GitHub.com introduced actor-based APIs (the ability to assign Copilot, bots, etc.), we needed to change how the CLI fetches, displays, and mutates assignees and reviewers. The old GHES path resolves everything through node IDs: you fetch all assignable users, present them, and send IDs to the mutation. The new actor path works with logins directly and supports search-based selection.

I wired up the assignee side of this pretty thoroughly, but the reviewer side ended up taking a different shape, and honestly I'm frustrated with the asymmetry. Here's what I mean:

How assignees work:

There are two flows, create (pr create, issue create) and edit (pr edit, issue edit), but the actor-mode signal is threaded through both:

1. Feature detection → issueFeatures.ActorIsAssignable is checked in both create and edit entry points
2. Carrying the signal:
   • Create flows → set IssueMetadataState.ActorAssignees on the state struct that gets passed through to the survey and mutation
   • Edit flows → set EditableAssignees.ActorAssignees on the editable struct, which carries the flag through the survey, FetchOptions, and into mutation via AssigneeIds/AssigneeLogins methods
3. Metadata fetch → RepoMetadataInput.ActorAssignees tells the fetch layer to call RepoAssignableActors() instead of RepoAssignableUsers(), getting actors (bots, Copilot, etc.) alongside regular users. This is shared by both flows via MetadataSurvey → RepoMetadata.
4. Survey/UI → MetadataSurvey checks ActorAssignees to decide whether to build options from the actor list or the legacy user list, and whether to use search-based selection
5. Mutation → params.go checks ActorAssignees to send assigneeLogins (login-based) instead of assigneeIds (node-ID-based)

Each layer has an explicit flag that says "we're in actor mode." The flag flows top-to-bottom through both create and edit.

How reviewers work:

✅ = the same as assignees, ❌ = different

1. Feature detection → Same issueFeatures.ActorIsAssignable ✅
2. Carrying the signal:
   • Create flows → set IssueMetadataState.ActorReviewers on the state struct ✅
   • Edit flows → EditableReviewers has no ActorReviewers field. There's nothing on the struct to carry this signal. Instead, the edit flow piggybacks on editable.Assignees.ActorAssignees to decide between GraphQL and REST reviewer updates, which is even more confusing since the reviewer actor decision is keyed off an assignee flag. ❌
3. Metadata fetch → RepoMetadataInput has no ActorReviewers field. There's no actor-aware reviewer fetch. When search isn't available, reviewers fall back to AssignableUsers + Teams (the legacy path) regardless of whether we're on github.com or GHES. ❌
4. Survey/UI → MetadataSurvey uses state.ActorReviewers && reviewerSearchFunc != nil for the fetch-skipping decision, so the actor flag is partially involved. But the downstream option-building and selection code only checks reviewerSearchFunc != nil, not the actor flag directly. Compare this to assignees where state.ActorAssignees is checked at every step (fetch input, option building, login extraction). ❌
5. Mutation → params.go checks IssueMetadataState.ActorReviewers to send logins vs IDs. This part is symmetric. ✅

So the mutation layer and the top-level state are fine, but the middle of the stack (the editable struct, the metadata fetch, and the survey option building) all have the assignee actor path but not the reviewer equivalent. Reviewers work today because search-func-presence happens to be a reliable proxy for "are we in actor mode," but it's a different pattern than what assignees use.

What should we do about it?

I'm not sure the right fix is just adding ActorReviewers to mirror ActorAssignees at every layer. That would make things symmetric but also doubles the surface area. What I'm wondering is whether we should instead have a single capability signal, something like an ActorAPIs or ApiActors flag, that both assignees and reviewers key off of. The feature detection is already shared (ActorIsAssignable gates both), so having one flag that means "this instance supports actor-based APIs" and grouping all the actor-vs-legacy branching under that feels cleaner than per-entity flags threaded through every layer.

Not addressing in this PR since the scope is assignee metadata for create/edit flows. The reviewer paths work correctly. I'll open a follow-up PR to tackle this frustrating asymmetry.