sema: r401 acquire-wait hold bound + session-wide exactly-once capture memory

Two fixes for the streams2 / multi-stream ordering class, both verified on
fresh boot r401 with the acquire gate enabled:

1. sema_wait_hold_ms (new module param, default 4000 ms) replaces the
   hardcoded 100 ms acquire-wait bound in svc_run_ops. The old bound is
   shorter than one emulated GR launch completion (0.5-1.6 s observed), so
   a D2H readback's ACQ_CIRC_GEQ on the producer channel's progress
   counter (op=3 pay=4 on 0x20400ffd0) gave up and ran BEFORE the scale
   launch wrote d_c2; the client then verified pre-scale data
   (bad=32767). r401 log: the same entry now holds ~1.2 s across
   cur=1->4 and runs after GUEST GR LAUNCH OK (copy-back optrace
   92315.594824 with dst16_after = the post-scale bytes). Fail-open is
   preserved: a genuinely unsatisfiable acquire still expires, just late
   enough that the dependency's work has landed (late-but-correct over
   early-and-wrong).

2. svc_gr_seen: a session-scoped open-addressed (push_va, hash) table
   behind svc_gr_cand_push_seen(). The 4-slot candidate ring + 8-VA
   history evicted a real capture within ~12 later captures, so a true
   replay of an already-forwarded launch was re-captured and re-executed
   (r399: the same nine launch pushes re-submitted every ~10-11 s for
   minutes). Cleared in svc_session_flush because a new client's
   identical-content pushes restart their release counters - a
   boot-scoped table would silently drop them (LAUNCH-SKIP).

Also adds tools/cuda-ab/streams2d.cu: streams2 with per-array/per-4KB-block
diff reporting plus the device pointer dump, which localised the remaining
failure to the D2H staging write path (our staging-page resolution vs the
guest's view).

0 files changed, 0 insertions, 0 deletions