vgsp-sema r548: never consume a GR launch whose forward is still owed (r547 saxpy stall)

Live evidence (r547, 16+ min stuck victory_saxpy): both launches were
captured, deferred by the r541 (unexecuted device write) and r543
(partial argument set) guards, and left as unoffered candidates - then
every later pass re-decoded the entries as replays (LAUNCH-SKIP;
already captured=1) and the consume path dropped them with no GR LAUNCH
and no GR-COMPLETE-SW for the client, whose cudaDeviceSynchronize waited
forever (client-side strace: RM-control poll loop, libcuda condvar
500 ms retimer; host log: consume idx=105/106 every ~2 s, releases never
authored for rel=0x204827f7c).

Three coordinated changes:
 - svc_gr_arg_defer_ok: per-VA latch table (8 slots) instead of a single
   slot. Two interleaved launches made the single slot ping-pong (each
   call saw the other VA and re-deferred both forever); each VA now gets
   exactly one deferral inside the 30 s window and the next sighting
   proceeds, so the guard delays without ever hanging.
 - svc_decode_stream: a fresh decode pass no longer wipes a valid,
   never-offered candidate (a deferred forward is not stale). The
   capture path already rotates to a free candidate-ring slot.
 - pump no-capture hold: fires for a REPLAY whose push VA still has an
   unoffered candidate in the ring (owed forward), forcing a fresh
   capture + request per bounded window; and when the window expires
   with the forward still owed, svc_gr_owed_resolve authors the QMD
   completion release from that candidate and marks it consumed, so an
   entry is never consumed without a completion (no late double-run).

New counter gr_owed in the sema-svc drain line; hold log carries owed=.

0 files changed, 0 insertions, 0 deletions