vgsp-sema: discover direct-GL CE userd pages; complete kick slots; post-reboot diagnostics

The direct-GL GL client's CE channels (beef0101/0102) declare a
pool-relative FB control page (0x244f800 / 0x244f400 in r1656) while their
GPFIFO ring is mapped in guest RAM, and their ring publishes from slot 2
(entry 0 stays zero). The entry-0 layout gate could never fire, the BAR0
fallback rejects offsets past its 16 MB shadow, and the GR-only VRAM shape
scan never ran for them, so the channels retired with submissions=0 and
the client's CE releases were never applied.

r1661/r1663 evidence: enabling the VRAM shape scan for the beef CE family
(hole-tolerant entry validation, newest-slot required, a GET bounded to
one ring) finds the real control page (fb 0xa00000, put=1) and the CE push
at 0x40e0000 decodes; beef0101 now retires submissions=1 with its
semaphore releases applied.

Also:
- resolve the non-pool direct-GL semaphore window (0x4000000..0x4300000)
  through every published VAS translation (the general resolver can name
  a stale page while the client polls the beef0300 walk page);
- author 0xffffffff in the beef channel's 128 kick-slot records (the
  glcore 570.144 kick wait polls exactly that payload; r1662 writes are
  visible in the guest page, but this is not yet the X-server wall);
- one-shot nonzero-word dump of the beef0100 push (r1663 proved the GR
  init push's host semaphore is a true 32-bit VA 0x4238000 payload 1 with
  hi=0 in v1, so that release is correct);
- name CE/GR in the VRAM-scan adoption line.

Next wall (r1663): the X server spins in _nv015102rm/os_schedule (66 %) and
_nv018351rm (30 %) after the GL client's GLX request; GZDoom blocks in
_xcb_wait_for_reply. The display UPDATE completion event was posted and
re-posted at 12:12:20, so this is the flip/GLX-sync path, not the lost
UPDATE event.

0 files changed, 0 insertions, 0 deletions