Brief: review the P7 edge-door plan

Review docs/superpowers/plans/2026-09-28-instance-moves-p7-edge-door.md against the code in this checkout (branch instance-moves-p7, based on main with P0 merged) before anyone builds it.

The design it implements is on branch docs-instance-moves-design: git show origin/docs-instance-moves-design:docs/superpowers/specs/2026-09-24-instance-moves-for-every-app-design.md. Read §0 (Paul's rulings, fixed: do not re-argue them), §8 and §10. Your own recommendations that became those rulings are in CODEX-RULINGS-INSTANCE-MOVES.md beside it.

What was decided while planning, and why

• The credential is a console-minted random key whose SHA-256 sits in a record under control/door-keys/<account>/<app>.json, signed with the deployment's root release key. Boxes verify it against CARLOS_RELEASE_PUBKEY, which the edge already holds (e.staticPub). Rejected: the relay's HKDF-per-box-master pattern (a master staged by hand on every box, an infra change per box), and an unsigned hash record (any bucket writer could add a key, discussion #171).
• Remote ownership comes from new account/app fields in each box's edges file, so the request path never reads the bucket (the edge's rule). A host whose publisher predates the fields is refused.
• The door calls the ordinary Edge.ServeHTTP after authenticating, stripping the key and the hop headers, checking ownership, and setting a context mark. The mark widens X-Forwarded-For trust in setForwarded and clientIP only; the backhaul one-hop refusal still reads hopVerified.
• Dormant: no socket unless CARLOS_EDGE_DOOR names a path.

What to look for

1. Authorization holes. Any request a door caller can shape that reaches an instance of another app, or the tunnel host, the store door, the steering probe, or any other ServeHTTP branch that runs before the route lookup. Specifically check the login POST, which ServeHTTP re-resolves by its next parameter (edge.go around 1400-1446), not by r.URL.Path, while the door checks ownership by r.URL.Path.
2. Trust leaks. Whether rewriting RemoteAddr from the caller's X-Forwarded-For, or the forwardedTrusted widening, lets a door caller spoof anything the edge or the gate relies on beyond the visitor address.
3. The signing choice. Is signing door-key records with the root release key (the key that moves stable) acceptable, or does it need a scoped grant (internal/release/grant.go)? Does any existing verifier accept a root-signed wrapper of a different kind, so that a door-key record could be replayed as something else, or vice versa?
4. Revocation and failure behaviour. The 30 s mirror; dropping records that fail verification but keeping the last map on a list failure; what a console with no signing key does.
5. Plan quality. Tasks whose interfaces don't line up, steps that name helpers or fixture fields that don't exist (check each against the code), tests that would pass without the change, and anything the rulings require that no task builds.

Cite code as path:line and check each citation. Findings first, ranked P1 (must fix before building) / P2 (should fix) / P3 (note), each with the failure scenario and a suggested fix. Then one line on whether the plan is ready to build once the P1s are fixed. Keep it under about 2,000 words.