Astra: final review of the instance-key build (second reader)

Review the code on branch instance-key-build, base 0901e835 (main) to HEAD. The plan is docs/superpowers/plans/2026-10-10-instance-key-provision.md, rev 5.1, which you passed as ready to build in round 7. Its "Built" note lists where the code diverges from the plan, by ruling. Rulings 1–30 bind.

What it does. It is region HA's L21: the platform mints each instance's key.

• CARLOS_INSTANCE_KEY is written create-only into <host>.env on every launch path, and made durable (chmod, file fsync and directory fsync) before success. The open uses O_NOFOLLOW, and a failed write is truncated back.
• Replicas run only with the home's verified key, or with none.
• The claim launch source mints under the guard.
• The adoption verb (mounted nowhere until O6/O7) writes a writer-bound record and publishes it.
• On legacy boxes, the startup backfill adds the key to existing env files.
• Keys travel byte for byte through re-render and moves.

Judge:

1. Overwrite. Can any path overwrite, rotate or truncate a key a successful call reported? Can two processes of one instance hold different keys?
2. Durability. Can any path start an app before its key is durable, outside the stated exemptions?
3. Replicas. Can any replica launch path run with a key other than its home's, or mint one?
4. Disclosure. Does a key or its digest reach a log, an error, the console or a CLI listing?
5. Agent changes. Is every change to the existing agent behaviour (activator merge, start sequence, claim snapshot) safe for current fleets? Consider a symlinked env now failing a launch, and mixed versions.
6. Correctness. Are there bugs, races or untested guards in the diff?

Give findings P1/P2/P3 with file:line, then a verdict: ready to merge, or not.