Review brief: region HA plan 1b, round 1

You are an independent second reader. Review the implementation plan docs/superpowers/plans/2026-10-06-region-ha-1b-claim-readers.md at the commit named in the prompt, against the tree at the working directory (Go, module github.com/carlosframework/platform) and the approved spec docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md (rev 5.4; rulings H1–H19 in §0).

Fixed: do not re-argue

• The spec's rulings H1 to H19, and Paul's approval of rev 5.4.
• The scope rule: plan 1b builds only what needs none of the spec's L1–L20 claim/moves changes; everything listed under "Waits for the claim" is out of scope. Do not ask 1b to build those.
• The controller rulings recorded in the plan's header.
• Everything stays dormant behind CARLOSREGIONHA and changes nothing on a one-box region.

What to check

1. Does the code compile and do the tests pass as written? The author dry-ran every task on a clean copy of main; a "would not compile" finding should quote the line and say exactly what is undefined.
2. Does each test pin the behaviour its name claims, and fail with its mechanism removed?
3. Correctness: boxid.Enroll's evidence chain (signature, account, region, legacy tofu id, both directions of the roster), termfence's binding to the roster's cloud identity and H19 (terminated alone; absence never evidence), boxvolumes' records and Discharge (H19 and the 2-hour ruling), the edges-file claim reader (§5.4: withholding, stamps, caching, read failures), root's update refusal (§5.10's half), the bucket policy (would any statement break something that works today, especially existing writers under control/).
4. Dormancy: anything that changes behaviour with CARLOSREGIONHA off, or on a one-box region.
5. Task boundaries: a task that cannot be built and tested alone, in order.
6. Scope: anything that quietly depends on an L-change, or writes a claim.

Output

Findings ranked P1 (would not compile, a test fails, or unsafe), P2 (wrong or missing), P3 (clarity). Each: task and step, the problem, the evidence (file:line, or the plan's own line), and a concrete fix. End with a verdict: ready to build, or not ready.