v2-platform: 10 OTA watch runtime — poll, validate, partial hot-swap, rollback

Parent

#274 (v2 platform services spec)

What to build

The OTA runtime: a watch mode where the static container never restarts for code changes. It polls the account's FastKV read URL (~5s), validates the trust chain (on-chain config signature + per-remote SRI), and hot-swaps ONLY the remotes whose URLs changed, following the lifecycle strategy proven by the hot-swap prototype (shadow-flip or its measured better). Rollback re-imports the cached last-good URLs on any failed swap. This is the mechanism that turns a publish into "the app updates within seconds" — the workshop loop, the agent loop, and zero-downtime production deploys all ride on it.

Acceptance criteria

• A config change on FastKV is reflected by the running host within seconds, without restart
• In-flight requests during a swap are never dropped or served half-old/half-new (per the prototype's validated strategy)
• Only remotes whose URLs changed are re-imported (partial swap)
• A swap whose new remotes fail SRI or import rolls back to the last-good graph and keeps serving
• Repeated swaps over a day show no leaked connections, handlers, or module graphs (per the prototype's measurement harness)
• The e2e loop (deploy → publish → running app updates, no restart) is covered by the regression stack

Blocked by

• #277 (hot-swap lifecycle prototype — the strategy must be proven before this is built)
• #281 (all web plugins grafted — the swap operates on the grafted graph)

Start with the hot-swap lifecycle prototype in #277 and confirm that #281's web-plugin grafting work is available before designing the runtime. Trace the FastKV polling and trust-validation requirements, then use the prototype's measurement harness and regression stack to verify partial swaps, rollback, request continuity, and deploy-to-update behavior without a restart.