sema-svc: deliver UVM CE tracking releases without host-side pins

The runtime client's registration stalled when no guest-side pin scanner was
running: the content rescue refused to run before the pool semaphore was
translated (its expected payload was unlearned), and unreadable CE entries
were consumed after two failed rescues ~40 ms apart, dropping the client's
wait. The push pages then could not be found within the entry's grace window.

- rescue: drop the learned-payload gate (the matcher only needs the channel
  rank and the release shape); keep unreadable CE entries pending for
  sema_ce_grace_ms instead of consuming after a fixed attempt count
- expected payload: re-learn from the pool whenever it advanced (a deferred
  release could land after the first read, leaving the expectation stale)
- matcher: require the expected payload exactly and validate the read-back
  stream carries it, so a recycled page of an older push cannot be pinned
- scan: descending full-range pass (the work allocations live in the high
  RAM block) plus a +/-512 MB near pass around the verified push-buffer base
- releases decoded with an untranslated semaphore are queued and applied
  when the page appears (svc_pending_add on both decode paths)
- a CE push that reads as a plausible stream but carries no release for the
  channel is re-routed through the rescue instead of silently consumed
- new module param sema_rel_recover (default off): after grace + rescue,
  apply the channel's expected tracking value so the client's wait clears;
  counter-visible as releases_recovered, distinct from sema_fake_rel

Evidence: fresh boot, real releases, no host watcher, no kprobes - the six
UVM CE first pushes are found by content rescue, their releases applied, and
the client reaches cudaGetDeviceCount rc=0 (it then waits for the third
push, which this change routes to the rescue).

0 files changed, 0 insertions, 0 deletions