Review brief: region HA plan 1a (foundations), round 1

You are an independent second reader. Review the implementation plan docs/superpowers/plans/2026-10-05-region-ha-1a-foundations.md at the commit named in the prompt, against the tree at the working directory (Go, module github.com/carlosframework/platform) and the spec docs/superpowers/specs/2026-10-04-region-ha-box-placement-design.md.

Fixed: do not re-argue

• The spec's rulings H1 to H9.
• The split into 1a (no claim dependency, this plan) and 1b (after internal/claim lands). Do not ask 1a to wire anything into create, reconcile, the activator's restore path or relocation.
• The three departures the plan states at its top (content hash in place of S3 version ids; the base64 RSA identity signature; snapshot as a periodic full publish). Report only if one fails to keep the spec's property.

What to check

1. Does the code compile and do the tests pass as written? Read each task's code against the real tree: every identifier, signature, import and file path it uses from existing code (release.Store, registry.Timer, registry.Route, edgesFile, foldHomes, edgesFilePlacementView, views, markStale, testKeyFP, provision.InstanceID, the ec2 SDK types, unix.Inotify*). Name the exact line that would not compile or the test that would fail, and why.
2. Does each test actually pin the behaviour its name claims? A test that passes for the wrong reason, or passes before the change.
3. Correctness of the mechanisms: the manifest's ordering under concurrent or late writes; readStable and symlink races; the inotify watcher (event parsing, lost events, new directories, close); dialBeats against every pre-existing home-map rule; Verify in boxid and termfence; the bucket policy statements (would any statement deny something that works today, especially lease releases or existing writers under control/?); the EventBridge and SQS tofu.
4. Additivity: anything that changes behaviour on a one-box region or breaks a reader of an existing wire shape.
5. The Review Focus list: is each of the five pinned by a test in the task that owns it?
6. Task boundaries: a task that cannot be built and tested alone, in order, with only the earlier tasks present.

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 exact evidence (file:line in the tree, or the plan's own line), and a concrete fix. End with a verdict: ready to build, or not ready.