fix(review): ensurePullRequestAssignee always fails against GitHub App installation tokens (198 Sentry events)

[JSONbored]

Summary

Every attempt to assign a PR to an agent via ensurePullRequestAssignee fails with a GitHub-side rejection — 198 events, 100% failure rate for this operation.

Evidence (Sentry)

GITTENSORY-1G — HttpError: Assigning agents is not supported with GitHub App installation tokens. Use a user token (personal access token or OAuth token) instead. First seen 2026-07-07, last seen 2026-07-08, 197-198 events. Full stack trace already captured:

src/github/assignees.ts:51 (ensurePullRequestAssignee)
  → octokit.request("POST /repos/{owner}/{repo}/issues/{issue_number}/assignees", ...)
src/services/agent-action-executor.ts:928 (performAction)
src/services/agent-action-executor.ts:530 (executeAgentMaintenanceActions)
src/queue/processors.ts:3184 (runAgentMaintenancePlanAndExecute)
src/queue/processors.ts:2556 (maybeRunAgentMaintenance)
src/queue/processors.ts:3422 (reReviewStoredPullRequest)

Tagged kind: agent_action_execution_failed, actionClass: assign.

Root cause (Sentry Seer — matches the evidence exactly)

GitHub's REST API does not support assigning non-collaborator "agents" via a GitHub App installation token at all (confirmed by GitHub's own error message, linked in the Sentry issue) — this call can never succeed with the auth model this repo uses. Seer's summary: "Catch the GitHub 403 'assigning agents' error in ensurePullRequestAssignee and return applied:false to trigger the existing label fallback." A label-based fallback for exactly this case appears to already exist in performAction/executeAgentMaintenanceActions — it's just never reached because the error propagates uncaught instead.

Requirements

1. Catch this specific GitHub error (403, "Assigning agents is not supported...") in ensurePullRequestAssignee and return a structured { applied: false, reason: ... } (or equivalent) instead of throwing.
2. Confirm the caller (performAction) actually falls through to a label-based equivalent when applied: false, and that path is exercised by a test.
3. Don't swallow other, unrelated errors from this same call — only this specific, permanently-unsupported operation should degrade gracefully; a genuine transient failure should still surface.

Deliverables

• Code fix + regression test reproducing this exact error and asserting the fallback fires.
• Confirm via Sentry after deploy that this specific error stops recurring.

[linear-code]

JSO-3616