[Bug]: transient 403 at Gate finalize still orphans the check (P1)

[JSONbored]

Discovered in the agent-layer readiness sweep. The #730 fix (PR #732) did not cover the finalize path.

Problem

isCheckRunPermissionError (src/github/app.ts:293) treats any HTTP 403 as permission_missing. GitHub secondary/abuse rate limits return 403. When the finalizing createOrUpdateGateCheckRun (src/queue/processors.ts:1211) hits a transient 403, it returns permission_missing → only an audit row is written, the pending check is not finalized and no throw → the error-finalize catch never runs. The 'Gittensory Gate is evaluating' check is left in_progress forever, blocking merge.

Fix

Distinguish permanent (403 'resource not accessible by integration') from transient 403 (secondary rate limit; carries Retry-After / x-ratelimit-remaining:0). On transient → retry or fall through to neutral error-finalize so the pending check always terminalizes.

Why it gates the agent layer

A gate that takes actions must never hang. P1.

Acceptance

• Transient 403 at finalize → check ends neutral (not stuck); permanent 403 → permission audit as today. Test covers both.

[JSONbored]

Not a bug — verified against the actual code (2026-06-17). The audit claim that a transient 403 at gate completion 'only writes an audit row, does not finalize' is incorrect: src/queue/processors.ts:1246-1249 does finalize the pending check to neutral on a completion-403 permission_missing (the #732 fix), and the comment at 1241-1245 explicitly explains it is handling exactly the transient secondary-rate-limit case. The existing test 'finalizes the Gate to neutral instead of leaving it in_progress when gate completion fails' (queue.test.ts:1118-1174) mocks a secondary-rate-limit 403 on the completion PATCH and asserts the check finalizes to neutral. Changing the classification (as initially attempted) would alter tested, intentional behavior (it would make the job re-throw and retry instead of finalize-and-complete). Closing as already-handled.