Record what applying the A8 ruleset settled, including the verified actor id

[404SecNotFound]

What this changes, and why

Docs only — docs/OUTSTANDING.md. The A8 entry described the live application as pending and carried an unverified guess. Applying it for real answered four open questions, recorded as measurements rather than left to be re-derived.

The one flagged as unverified in #42:

question	answer
Is actor_id: 5 / RepositoryRole the repository admin?	Yes — current_user_can_bypass returned always for the owner

Three more from the same run:

• An invalid field aborts the whole PUT. The evaluate attempt returned 422 and changed nothing, so a bad apply fails closed rather than half-applying. That is the property the disable-verify-enable procedure leans on, now demonstrated rather than assumed.
• A one-field PUT preserves the other rules. -f enforcement=… alone did not wipe the rule set.
• The bypass cannot be confirmed from an automation session at all. GitHub omits bypass_actors for callers without admin, and current_user_can_bypass answers for the calling token — never for automation, always for the owner.

That last one is the important one. An automation session can read enforcement, the rules and the required checks, and cannot read the bypass — so "CI confirmed the ruleset" can never cover the half that decides whether main is mergeable. Only a maintainer can check it.

It also corrects something I got wrong in session: I earlier reported the live bypass_actors as [], reading through a .get() default. The key may simply have been absent for my token. The conclusion happened to be right, but the method could not have distinguished "empty" from "not visible to me" — precisely the confusion this repository exists to refuse.

And a live application is not proved by a successful merge. Merging with --admin while enforcement is disabled succeeds for the wrong reason: the flag is a no-op and nothing was gated. Read enforcement and updated_at back and confirm the timestamp moved. A re-enable that silently never reached GitHub looks identical to one that worked — that happened once during this application and was caught only by comparing timestamps.

Evidence

• The defect was reproduced first — n/a in the usual sense: this records observations from a live application. Every row is a fact observed during it, traceable to API output seen in session.
• I mutated the fix — n/a, nothing executable is added. Docs only, no assertion to mutate.
• python -m pytest tests/ -q passes.
• python tests/test_evasion.py — 34/34.
• ruff check src tests eval tools passes.
• python tools/readme_facts.py --check passes — no count moved on this base.
• python tools/verify.py — 16 passed, 0 failed, 0 not evaluated.

If this changes detection / an evasion

• n/a for both — documentation only, no src/ changes.

Anything a reviewer should push back on

• None of this is enforced by a test, and the natural test — diffing the committed ruleset against the live one — is now known to be impossible from CI, because the token cannot read bypass_actors. A partial drift check covering everything except the bypass is possible; it might also give false comfort on exactly the field that matters. Worth a decision rather than a default.
• actor_id: 5 is verified for this repository and this account. I have not established that the mapping is a documented GitHub constant rather than an implementation detail — treat it as "confirmed here", not "known universally".
• The A8 entry is long now, reading more like a runbook than a checklist item. Deliberate, given how close this came to locking main, but a fair call if you would rather the procedure moved to its own page.

Note on ordering

#45 also touches the derived doc word count. Whichever of the two merges second will need one regeneration commit — the count is 115,000 on either base alone and 116,000 with both. Not a conflict in the git sense; the checker will simply ask for readme_facts.py --write. I will handle it on whichever lands second.