vgsp-gr: read the fixed CB from the engine-visible page and never deliver a header-only VS image

The GL draw's VS was reading two wrong inputs. First, the fixed-CB copy
resolved the client VA through a learned/FB layer first, so it read the
emulated BAR1 vidmem shadow - a buffer the engine never writes - and
delivered unrelated vidmem (r1490 first=09037223 00000004; r1482
oscillated between a float row, method words and zeros). Resolve the CB
the way the engine does: channel VAS, every registered VAS page-table
walk, then the GR relocation resolver; only a SYS answer is content-valid
and an FB answer is flagged. The matrix gate now requires four
normal-magnitude floats in c[0x0][0x80..0xbc] (r1492 accepted a method
page as a matrix); a rejected read authors the identity MVP.

Second, the captured 1536 B VTG upload is spliced at a page boundary: the
delivered image was the SPH header plus ZERO SASS, so the VS executed no
code. Reject captured program images whose SASS body [0x80,min(len,0x200))
is zero (the real-upload ring record, the 020a0481 cache and the window's
own upload all pass the gate) and deliver the built-in known-good VTG
image (the client's own SPH V4T1 020a0481 + SASS) at the bind VA instead;
sema_gl_vs_img=0 restores the old behaviour.

Diagnostics: cb-matrix/cb-const dumps of every VS-read constant block,
SPH-ALIAS code4 words at the bind, and MME-VSTREAM post-relocation
stream/limit/address payloads.

r1491-r1493 (VP_MODE=6, RT0=1): the bind page now shows the real SASS
(code4=ff047321 0000a0ff ...) and the CB/identity delivery is logged, but
the draw still produces no fragments (retirement 0-3/900 = the forced MME
seed pages only; xwd decoration rows only). Next wall: the vertex
attribute/staging fetch (slot-57 0x39c8 data and the staging scratch
0x36/0x37), not the shader image or the fixed CB.

0 files changed, 0 insertions, 0 deletions