vgsp-sema: software-author the GR launch completion release when the physical forward fails (ISSUE-0002)

r51/r52 root evidence: the second session's GR launch was forwarded to the
physical engine; the backend timed out (qmd_rel=5 want=6 after 5 s) while the
hold resolution applied only the *stream-recorded* channel release. The QMD
launch completion semaphore (the word the client polls in its launch-
completion wait) is carried by the GR candidate (gr_rel_va/gr_rel_payload),
not by the release records, and nothing authored it on failure - the client
spun forever in the completion wait and the pump went idle (pushes=1207,
pending=499, crel frozen).

Fix:
- a GR hold waits for the backend's bounded outcome (12 s bound vs the
  backend's 5 s poll) instead of the 500 ms CE copy bound, so the release is
  never authored while the physical submission is still writing guest pages;
- on hold resolution without a successful hardware copy (timeout, abort,
  expiry, or a release0 page the backend could not observe), the QMD release
  is software-applied forward-only (read/compare, absolute payload write) -
  idempotent against a late engine write and never rewinds the tracker;
- a GR capture whose request did not queue (refused/backend busy/hold active)
  authors the same release inline when the CUDA bridge is disabled (the
  bridge job owns it otherwise);
- new work_guard counter gr_sw_rel names how often the fallback authored a
  release, and each write logs its va/payload.

Validated: c1 GREEN, c2 GREEN in the same VM (r54; CE->GR, mail + VADD
STATUS OK). In that run the forward succeeded so gr_sw_rel stayed 0; the
timeout branch is the one r52 proved is reachable.

0 files changed, 0 insertions, 0 deletions