Description

So the diff here is gnarly but bear with me 😅. In #13009 I was frustrated seeing the divergence between how actor types were handled for assignees vs reviewers (this is my fault I'm sure).

Now, with all the context, I recognize that these two paths for handling actor types are not actually different. They're keying on the same feature detector field (ActorIsAssignable) anyway, but they ended up diverging and checking different things across the stack:

The divergence

There are two flows: create (pr create, issue create) uses IssueMetadataState, and edit (pr edit, issue edit) uses Editable. The actor signal was carried differently in each, and assignees vs reviewers were handled asymmetrically:

Create flows (via IssueMetadataState):

Edit flows (via Editable):

Shared (used by both flows):

So the source was always one signal, but it fanned out into different field names on different structs, with reviewers missing coverage in the edit path entirely.

After this PR, it's just one field at every level:

What this PR does

This PR calls it like it is: these are all the same capability signal.

1. It consolidates ActorAssignees and ActorReviewers into a single ApiActorsSupported field that lives at the shared level on each struct (Editable, IssueMetadataState, RepoMetadataInput). Both assignees and reviewers key off the same signal.
2. The feature detector field is also renamed from ActorIsAssignable to ApiActorsSupported so the name is consistent from detection through to consumption.
3. BONUS: I also expanded the documentation on the feature detector to describe exactly when this codepath can be consolidated and what GraphQL schema additions to look for to confirm GHES support is ready. Previously the feature detector was multi-purposed and the documentation didn't reflect the breadth of what it affects.

Every branch site in the code is now tagged with // TODO ApiActorsSupported so a future cleanup can be done with a single grep.

Why one field and not separate feature detectors?

You may be wondering: these seem like somewhat different features (actor assignees vs actor reviewers vs search-based selection), so why not have separate feature detector fields?

In short, I believe it is simpler to group them. The harm is that, sure, maybe Copilot coding agent could hypothetically be allowed on GHES sooner than Copilot code reviewer or the other login-based mutations. But the complexity would matrix really quickly IMO, and the juice isn't worth the squeeze.

So: group all the actor stuff together, control it with one field. The state is easier to reason about and we can ship GHES support with more confidence because we know these things are compatible.

Acceptance & Regression Testing

38 scenarios tested across github.com and GHES 3.20, all passing: Acceptance test results

Notes For Reviewers

Commits are intentionally grouped. Some are chunky, but thematic, and IMO it's easier to review this way.

Commits

1. 3c00ffd — Core change: Consolidate actor signals into ApiActorsSupported on Editable, IssueMetadataState, RepoMetadataInput
2. ae5e857 — Rename feature detector from ActorIsAssignable to ApiActorsSupported
3. 92f205e — Document GHES removal criteria on the feature detector struct
4. 6a68ebc — Nit: simplify redundant expression in survey.go where RepoMetadataInput.ApiActorsSupported was rechecking conditions already gated upstream
5. bff468b — Fix: wire up @copilot assignee replacement in pr create and add [bot] suffix for replaceActorsForAssignable mutation (bugs introduced in Use login-based assignee mutation on github.com #13009)
6. 391e661 — Fix: use useReviewerSearch consistently in the reviewer prompt path (matched existing assignee pattern)