Post-merge verification hardening

[batbrainy]

Problem

Post-merge review of main at 3c938a2 found submission-blocking defects in the recovery verifier and reviewer documentation:

• recovery can recreate the worker in live mode despite promising a fixture-only run;
• fixture command failures and restart-count drift are not all asserted;
• the README/checklist do not establish an empty fixture volume after live startup;
• exactly-once-adjacent and pre-commit recovery wording overstates the proven guarantees;
• the design brief exceeds the assignment 1-2 page budget.

Planned files and why

• script/verify_recovery.sh and spec/docker_compose_spec.rb: keep recovery fixture-scoped and make every required verdict executable.
• README.md, docs/SUBMISSION_CHECKLIST.md, the dated recovery evidence, and fixtures/github/README.md: make the reviewer path sequential, accurate, and historically honest.
• docs/DESIGN_BRIEF.md, ADR 0005, IMPLEMENTATION_PLAN.md, CLAUDE.md, and related test comments: narrow guarantee language and meet the brief length constraint.

Deferred / out of scope

• No runtime endpoint, ingestion, enrichment, database, schema, dependency, or Compose-topology changes.
• No authentication or new infrastructure.
• No submission email until a fresh clone of the merged default branch passes every gate.

Acceptance

• Recovery remains fixture-mode after every recreate and fails on command/count mismatches.
• Clean live startup and empty-volume fixture verification are separate and reproducible.
• No positive exactly-once or complete-capture/enrichment implication remains.
• Design brief renders to at most two US Letter pages.
• CI and the full fresh-clone verification pass.

[batbrainy]

Authoritative fresh-clone review found two documentation mismatches after PR #36 merged: the forbidden-claim scan was case-sensitive (-I rather than -i), and the recovery script top comment contradicted its correctly isolated test-service phase. Reopening until the follow-up fix is merged and the final SHA is reverified.