feat(workplan): close STATE-WP-0083-T07 — central reports schema ok at head

First execution failed in a way that proved the design: the pre-upgrade hook
applied both migrations and deleted itself on success, then the k3s tunnel
dropped before the API could roll. Schema was briefly ahead of code — the safe
direction, and why additive migrations were the right shape.

Records two gaps it exposed: a successful migration leaves no trace because of
the hook delete policy, and bridge status reported a dropped tunnel as
connected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006

workplans/STATE-WP-0083-forge-derived-projection-reset.md

@@ -220,7 +220,7 @@ manual inspection confirms.
 
 ```task
 id: STATE-WP-0083-T07
-status: todo
+status: done
 priority: high
 ```
 
@@ -250,3 +250,34 @@ of defect as a projection that cannot name its source commit.
 Acceptance: central reaches `head`; `review_contracts` exists; the mechanism is
 declared in the chart; a mismatch between code and schema is reported rather than
 tolerated.
+
+**Done (2026-08-26).** Central reports
+`schema: {status: ok, applied: d1a2b3c4e5f6, expected: d1a2b3c4e5f6}`.
+`review_contracts` exists. Both pods run `main-97c8762`.
+
+The first execution is worth recording, because it failed in a way that proved
+the design. The `pre-upgrade` hook ran, applied both migrations and deleted
+itself on success — then the k3s API tunnel dropped (`unexpected EOF` →
+`connection refused`) and Helm could not read the deployment to roll the API.
+The release wedged at `pending-upgrade`; no pod rolled.
+
+The schema was therefore briefly *ahead* of the running code, which is the safe
+direction and the reason additive migrations were the right shape: the old image
+served correctly against the new schema throughout. A destructive migration in
+the same circumstance would have taken the service down.
+
+Recovery was `helm rollback` to the last deployed revision — which clears the
+wedge without touching the schema, there being nothing to undo — then re-running
+the upgrade. The hook is idempotent, so the second run's `alembic upgrade head`
+was a no-op.
+
+Two things this exposed, neither yet addressed:
+
+- The hook's `hook-succeeded` delete policy removes the Job on success, so a
+  *successful* migration leaves no trace. That made it look as though nothing had
+  run when in fact everything had. Retaining a short-lived record of successful
+  migrations, not only failed ones, would have answered the question immediately.
+- `bridge status` reported `k3s-api-railiance01` as `connected` while holding a
+  stale pid, so its health signal did not reflect the dropped connection. A
+  tunnel monitor that cannot detect the failure it exists to detect is the same
+  defect class as a projection that cannot name its source commit.