Review brief: edge asset cache spec

Spec: docs/superpowers/specs/2026-10-24-edge-asset-cache-design.md (rev 3). Repository: carlos/platform at the commit named in the run prompt.

You are an independent second reader. The author is another model. Review the spec adversarially against the code in this tree and report what is wrong, not what is good.

Fixed points (do not re-argue)

• Paul's rulings R1 to R3 in spec §13.
• The scope in §0 and §2: pull-through only, build assets only, not the media roadmap's stage 1, no third-party CDN.
• The author's calls marked "my call" may be challenged only with a concrete failure (a mechanism that breaks, an attack that works, a cost that is unbounded), not on taste.

What to look for

1. Mechanisms that cannot do what the spec says against the current code. Cite file:line.
2. Attacks that work: cross-tenant reads, a personalised response cached for someone else, a stale or wrong owner's bytes served, a cache that one tenant can use to hurt another, a gate or import gate bypassed, a client forging the fill marker.
3. Interleavings: deploys with generation-managed routes, moves of a host between boxes (instance moves), replicas, aliases, a home disarmed or restarted, a purge racing a fill, an edge offline then back.
4. Cost: anything that adds per-app or per-box reads of the deployment bucket beyond what §4.2 states, or unbounded disk, memory or fills.
5. Provider boundary (§9) and rollout safety in a mixed fleet (§10).
6. Gaps in §12's tests that would let one of the above ship.

Output

Numbered findings, most severe first. For each: severity (P1 blocks the design, P2 must be fixed in the spec, P3 worth noting), the claim, the evidence with file:line, and the smallest change to the spec that fixes it. End with one line: "accept" if no P1 or P2 remain, otherwise "reject".