vgsp-sema: periodic GR discovery re-arm + FB-first fast path (FORENSICS-grv3 R1)

FORENSICS-grv3: the FB discovery worked for ranks 0..2 (content-discovered +
auto-pinned ap=2, ring_auto 6->9, gpfifo done 89->110, gr_rel 0->3), but the
guest only ever wrote ring entry0 for those three ranks during the scan
window, and the discovery epoch took its 60-pass cap and retired - the re-arm
existed only on channel registration - so the remaining ~8 minutes of guest
life had no scanning at all (890 "capped" messages, no pass after ~4189).
The first pin was also ~3.5 s late because the 6 GiB RAM walk ran before the
FB scan.

Changes:

1. Periodic re-arm (FORENSICS-grv3 sections 4-5A). Taking the epoch cap no
   longer retires discovery: the pass count resets, discovery rests
   SVC_GR_CONTENT_COOLDOWN (30 s) and then starts a fresh epoch for as long
   as any registered GR channel still lacks a ring. A registration batch
   still re-arms immediately (and now also clears the cooldown). When every
   registered GR channel has a ring, discovery stops with a single
   "discovery idle" log line. Passes stay one per 2 s and the cap/cooldown
   bounds the scanning duty cycle, so a permanently missing ring cannot
   hot-loop.

2. FB scan first + fast path (FORENSICS-grv3 section 5A). The emulated-VRAM
   scan (direct host reads, milliseconds, bounded to SVC_GR_CONTENT_FB_LIMIT
   at a page stride) now runs before the RAM walk and records ring
   candidates without requiring a push candidate. Push candidates are kept
   across passes (the ctx-init pushes are content-stable), so when every
   ring-carrying rank already has a push the pass pairs right after the FB
   scan and skips the RAM walk entirely: a late ring submission becomes
   visible within one 2 s pass instead of after a full re-scan.

3. Descending RAM walk with early exit. The push (release-group) walk now
   starts at the top of guest RAM - the same reasoning as the CE content
   rescue: the guest's work allocations live in the high RAM block (grv3
   pushes at 0x1028f...0x12df8..., 4.0-4.8 GiB) - and stops as soon as every
   ring-carrying rank has a push candidate, so the pass ends in about a
   second instead of a full 6 GiB walk. RAM ring candidates are still
   recorded here for boots whose ring is not in FB.

The pairing gate is unchanged: entry0 exact, the push parses end-to-end, the
release group sits at len-20 with this rank's slot and payload 1, and the
USERD at ring+0x2000 reads plausibly. Wrong or stale candidates pin nothing.
No module parameters were added or changed.

Not included (deliberately): the notifier/event completion path from
FORENSICS-grv3 section 5B. Section 3 lists it as the leading hypothesis only,
never observed live (the relevant logs are debug-gated), and 5B gates it on
this change showing the guest posts nothing more; the sema_dbg=Y experiment
is the discriminator. No speculative change was made.

Evidence: FORENSICS-grv3 sections 0, 4, 5A; 11-hostdmesg-grv3-r1.log
2727-2735 (FB pins), 2820-2823 (cap), 4060-4062 (capped tail); m104
17-host-m104-r1.txt:164-283.

0 files changed, 0 insertions, 0 deletions