vgsp: channel-reuse reconciliation + hint-flood stop (GR-STALL-stale-entry-chanswitch)

r229a evidence: victory_mail OK -> ctaid_probe attempt 1 printed DEVICE and
never completed (killed at 50 s); attempt 2 (fresh context) worked. The
retained window shows mail's teardown + session flush (gen 3) then, for
the whole first-attempt window, no channel registration and only the host
'completion hint rc=-2' flood (~0.5 s cadence, window reopened by the
completion-apply sites). No GR lines, no stale-* lines: the first launch
never reached the sema walk for the new binding.

- svc_thread hint: on rc == -2 (no event context to post to) stop
  reopening svc.post_hint_until; the next real completion reopens it. The
  flood was pure noise and obscured the real state.
- Channel-reuse reconciliation: svc_chan_registration marks a genuinely
  new binding (!same_gen) with wd_chanswitch; the channel's first pump
  pass drops every opdef slot bound to that handle (a dead context's
  withheld sets must not ride the reused channel - the r228 opdef-hold
  class) and, when the ring already carries content (put > 1), logs
  'GR-STALL-stale-wedge ... reason=stale-entry-chanswitch'. Captures stay
  enabled: the fresh client's own entries may already be at slot 0, and
  suppressing them would lose exactly the first launch this protects; a
  stale launch re-walk stays bounded by gsp_phys_gr_wait_max_ms and the
  m181 put-drop recovery. r220 hold guard and the m181 arm rule
  untouched.

Note: the phase2 witness for r229 was not readable at commit time
(/tmp/opencode/witness-r229-phase2.log absent); r229a is boot-side and
post-flush, so the attempt-1 window shows the guest sent no RM/channel
traffic for ~9.5 s - the reconciliation removes the host-side reused-
handle state classes; r230 will show whether the first-attempt launch
now reaches the walk. make kernel green.

(cherry picked from commit 21eb5bb0582aaa2409601a1a1466f7bc72841647)

0 files changed, 0 insertions, 0 deletions