vgsp: stale-replay leg is now strictly non-harmful (r235 second-client death)

r235-2 mechanism: at R2's ctx-init one pass fired 8 'stale-replay
rewind=1' lines (waited_ms=3491, incl. fresh channels with sub=6
put=1) and set each channel's pin-batch rewind cooldown to +24 s. The
rewind is the retry path for a fresh context (its init pushes are
decoded before the pins land; the rewind re-decodes them once the
translations exist), so disabling it killed R2 exactly like it would
every next client (r233 P2+, r235 R2-R4). R1 (working) fired zero
tokens. The 3 s window misread a normal init oscillation (rewind
replaying a just-consumed entry) as a rewind livelock.

- Removed the rewind cooldown entirely: wd_rewind_off_until field,
  write-back, watchdog clear/set and the svc_handle_map_add skip are
  gone. The pin-batch rewind is never manipulated by any recovery.
- stale-replay now requires SVC_GR_STALE_REPLAY_MS (10 s) of stalled
  position with consumption happening (a genuine livelock; r225 wedge
  was 42 s+), keeps its window accumulating until then, and clamps
  last_get = put at most once per put epoch (wd_epoch_done).
- Token updated: '... reason=stale-replay reset=0 clamp=1 ...' (no
  rewind manipulation; clamp is bookkeeping, a rewind may undo it).

Epoch legs (residual/dead-range), stale-entry, newbind window,
pending-map/rebuild path, kill-recovery, r220 guard and the m181 rule
are unchanged. make kernel green.

(cherry picked from commit 459384e02bba4eca04fa3eca2365a731a4a7a33a)

0 files changed, 0 insertions, 0 deletions