Require the exact gate / gate context after stale PRs emit it

[forkwright]

Finding

GitHub branch protection for Dioptron's main branch currently requires zero status contexts even though the repository's hosted verification contract emits the terminal gate / gate check. A green merge affordance can therefore exist without that check reporting.

The requirement must not be installed until every stale pull request that will remain open has emitted the real context on its current head. Adding the context first would strand those pull requests rather than verify them.

Evidence

• A fresh GET /repos/forkwright/dioptron/branches/main/protection returned required_status_checks.contexts = [], required_status_checks.checks = [], and strict = false on 2026-08-26.
• Current main is 8b3fbe8b7c34355498a26f6870b6ac5235a29738.
• At that commit, .github/workflows/gate-attestation.yml:1-6 defines one terminal gate / gate job for every workflow path.
• Pull requests opened before that workflow landed do not yet constitute evidence that their current heads can emit the new context. Requiring an unobserved context would make absence indistinguishable from failure.

Why this matters

With no required context, branch protection does not enforce the repository's stated verification boundary. With the context installed too early, legitimate stale pull requests can become permanently unmergeable. The safe sequence is to obtain a real check on each surviving head, then have the operator change repository authority once, using the exact observed name.

Desired correction

Keep branch protection unchanged until each surviving stale pull request emits a genuine terminal gate / gate check on its current head. Then ask the operator to require the exact gate / gate context on main; this issue does not authorize an agent to mutate branch protection.

Do not synthesize a status, rename the workflow to fit a guessed context, or use an admin merge as evidence that the requirement works.

Done when:

• every open pull request intended to remain has a real gate / gate result tied to its current head SHA;
• the operator explicitly applies the exact required-status-context change;
• a fresh protection read reports gate / gate as required; and
• a controlled failing or pending gate is demonstrably non-mergeable without an administrative bypass.