v0.109.1: re-apply preserves escrow custody + runtime status (live finding)

The QuotaGB hash change triggered a live re-apply that demoted the
escrowed demo to pending and wiped its runtime status. ApplyOffsiteTarget
now carries over EscrowState (custody tracks the preserved repo password,
not the coords) + status fields; fresh guests still land pending.
Red-proofed.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PSK5g6qYLknKj8u3QAFEr6

CHANGELOG.md

@@ -1,5 +1,21 @@
 ## Changelog
 
+### v0.109.1 — re-apply must preserve escrow custody + runtime status (live finding) (2026-07-10)
+
+Found deploying v0.109.0: including `QuotaGB` in the bridge's descriptor hash triggered a one-time
+re-apply on the demo — key-auth-first re-pinned cleanly (proven live, no password consumed) but
+`ApplyOffsiteTarget` REPLACED the target with the freshly-built struct: the escrowed demo was **demoted to
+pending** and its runtime status (last_run/size/snapshots) wiped — which would also false-trigger the new
+staleness alert after re-confirming.
+
+- `ApplyOffsiteTarget` now carries over the EXISTING target's `EscrowState` + runtime status fields on a
+  re-apply: EscrowState tracks the REPO PASSWORD's custody (preserved by `WriteOffboxSecrets`, never
+  rotated by this path), not the target coords; the status belongs to the runner. A fresh guest (no
+  existing target) still lands `pending`. **Companion red-proof:** dropped the EscrowState carry-over →
+  "a re-apply must NOT demote an escrowed target, got pending" → FAIL. Reverted.
+- Demo repair: one manual confirm-escrow (the deprecated fallback — truthful: the same already-escrowed
+  password) restored `escrowed`; a manual run restored the runtime status.
+
 ### v0.109.0 — SLICE 4: soft-quota gate + usage bar + offsite report status (2026-07-09)
 
 The shared-model soft quota (`quota_gb`) enforced controller-side (pairs with hub v0.41.0's