vgsp: stale-epoch/stale-replay wedge watchdog (GR-STALL-stale-wedge)

r225 evidence: after a client was killed mid-run, a fresh client's GR
channel (0x5c000059) was registered with a residual USERD put=101 from
the dead session. The m181 fresh-put-drop recovery never fired (the
fresh session never wrote a put - it was stuck at ctx-init, polling
MC_SERVICE_INTERRUPTS once a second), the completion-counter publish
stayed withheld (gr_pub_armed false), and the pin-batch rewind
(SVC_PIN_REWIND=8) pinned last_get at 93 on every injection batch: the
entry loop re-walked slots 93..100 forever, decoding nothing (rel=0, no
capture) and consuming with zero delivery. No capture -> no request ->
no bounded submit -> zero GR-STALL lines; the launch never reached the
bounded path because the session epoch itself was wedged.

- svc_gr_stale_wedge_check (pump pass, before the entry loop, GR only):
  tracks (last_get, put) per channel and fires after a 3 s no-progress
  window with two signatures:
  1. stale-epoch: residual put (put > 1, publish withheld, host believes
     the ring fully consumed): arm gr_pub_armed and void the withheld
     publish state (m181 semantics, counter_last-gated zeroing; no
     last_get rewind - the proven m181 rewind stays with its put-drop
     signature), so the fresh client's ctx-init wait gets its host edge.
  2. stale-replay: last_get pinned behind put while put == get and the
     loop consumed entries during the window (the rewind re-opening an
     already-consumed window): drop the window (last_get = put) and put
     the pin-batch rewind on a bounded cooldown (wd_rewind_off_until,
     cleared by new work) so the futile retry cannot pin the pump.
- svc_handle_map_add: channels under the rewind cooldown are not rewound.
- New per-channel watchdog state written back in the snapshot list
  (GRFIX NOTE rule); new diag token gr_wedge (drain line); new
  greppable line 'vgsp-gr: GR-STALL-stale-wedge h=... va=... last=...
  put=... get=... sub=... waited_ms=... action=recover reason=...'.

Green safety: fresh channels have put <= 1 (signature 1 inert) and
consume their first entries within milliseconds (submissions > 0);
signature 2 needs a stalled (last_get, put) pair for 3 s with no pending
producer work AND entries consumed during the window, which only the
rewind re-opening of a consumed window produces. make kernel green; only
pre-existing warnings.

(cherry picked from commit 6aa5709f57cc1d91a01205042d973d5b203c9bec)

0 files changed, 0 insertions, 0 deletions