HERTZ FIELD VERIFY — v0.34.0 REDISPATCH-TRUTH W1

Release/update evidence
- Initial `spt update apply --finish` only restarted already-installed v0.33.0 because counter 61 had not yet been fetched locally.
- `spt update fetch` returned UPDATE_STAGED:61.
- Second `spt update apply --finish` returned: `Updated spt-core to v0.34.0 and restarted the daemon — the new version is fully live.`
- Current target status: broker_image=0.34.0, broker_stale=false, net_up=true.

Criterion 1 — active remote RC survives daemon refresh: PASS
- Test target: deployah on HFENDULEAM.
- Remote viewer: KITSUBITO, upgraded to broker_image 0.34.0 before the acceptance attach. (Mixed 0.33 peer attempts failed in the source brain with `brain IPC read deadline elapsed`; they were not active sessions and therefore were excluded from the survival test.)
- Pre-refresh capture `/tmp/deployah-v034-acceptance.typescript` showed `PUMP_IPC_READER: spawned`, `[viewing 128x67 — your terminal is 0x0]`, and live deployah PTY output.
- With that remote `spt rc --view deployah` process still running, HFENDULEAM ran `spt daemon refresh`; result: `Daemon coordinator restarted in place — hosted sessions and connections were not touched.`
- The same remote RC process remained alive after refresh.
- Post-refresh stimulus `FIELD_VERIFY_RC_SURVIVAL: reply exactly RC_SURVIVED_REFRESH.` sent `SENT:deployah` and appeared in the SAME still-open remote transcript as `<msg from="hertz"/>`, after the refresh. This proves continued PTY delivery rather than merely a stuck viewer process.

Criterion 2 — fresh-generation logs contain no historical DISPATCH replay storm: PASS
- Refresh boundary in `C:\Users\decid\AppData\Local\spt-core\logs\daemon.stderr.log`:
  - line 2575: `BRAIN_UPDATE_RESTART: planned restart — cycling brain onto the swapped binary`
  - line 2578: `BRAIN_RESTART: planned update respawn (generation 1)`
  - line 2586: `=== spt brain stderr — generation 1 — pid 41528 ===`
  - line 2587: `BRAIN_UP: ... generation 1, start-reason update`
  - line 2605: `BRAIN_RESUMED: re-established 5 session cursor(s): [2, 4, 3, 1, 5]`
- Search from the v0.34 generation-0 boundary (line 1225) through the generation-1 refresh output found NO `DISPATCH:` records. In particular, no recurrence of historical IDs 3/741/4176/4496 and no pipe/buffer replay failures.

Criterion 3 — stall eviction count stays flat: PASS for the operational invariant, with counter-reset caveat
- Preserved v0.33 pre-update status: stall_evict_count=17, stall_evict_last_ms=1784195087635.
- Full broker replacement onto v0.34.0 initialized the new broker's in-memory counter to 0.
- Immediately before the tested brain-only refresh: stall_evict_count=0, stall_evict_last_ms=0.
- After the tested refresh and continued remote RC traffic: stall_evict_count=0, stall_evict_last_ms=0.
- Therefore no stall eviction occurred during update/refresh acceptance; the count stayed flat within the v0.34 broker lifetime. Numerically it is not 17 because the full broker replacement reset the telemetry. If the gate literally requires historical persistence `17 -> 17`, classify that telemetry subcheck FAIL; the no-new-stall behavior is PASS.

Overall milestone verdict: 3/3 behavioral PASS. One explicit observability caveat: stall_evict_count is process-lifetime, not persisted across the full broker replacement. Incident logs remain the before-picture.