vgsp-sema: SESSION 139 GR fill: reject float-shaped scan words + scan the deduped word-48 page

Two evidence-based corrections to the launch-data candidate scan:

1. Float-shape filter at all four scan sites (the three page scans and
   svc_gr_scan_cand): a word whose f32 exponent byte is in ~[0x6c..0x8f]
   (2^-19..2^16) is a plausible float scalar, not a device VA - device
   VAs (2^28..2^47) as f32 land in subnormal/tiny exponents. Root
   evidence (r789): the launch param page carries the kernel's scalar
   arguments (0.2f, 640.0f, 480.0f at +0x630 - the 640x480 viewport) and
   0x43f00000 = 480.0f was the fill's ONLY candidate - an unresolvable
   "arg base=0x43f00000" that drove the fail-closed diagnostic and the
   demand-loop noise for days. After the filter: 'fill cand n=0'
   (r790) - no false candidates, no false demands.

2. The bank-page scan now covers word 48: the QMD pointer-region pair can
   name a 4K page that also carries the program pair (r788: ptr[0]
   0xdff0febc00 word 34 shares its page with prog 0xdff0feb900), and
   svc_gr_page_note dedupes the first note (the program's, word 48), so
   the old 32..47-even filter left that page unscanned.

The remaining wall is content, not wiring: with the false candidates
removed the launch still refuses (n_data=0 vs min 16) because no scanned
source holds real device pointers - the param page holds scalars, the
QMD window page reads zero (its content would arrive via the driver's
i2m/LOAD_INLINE_DATA writes whose payloads are not in the push), and the
inline payload is the driver's zero stub. This matches the SESSION 130
zero-buffer finding and leaves the never-queued i2m copies (or the real
GPU path) as the only content sources.

0 files changed, 0 insertions, 0 deletions