vgsp: fix VAS-staleness on client restart + unstarve the ring scan (CONT.401)HEADmaster

Three fixes, all verified live (cycle r1696):

1. Parked-VAS age-out flood. CONT.400 kept the candidate parked after
   registering it UNVERIFIED, so with sema_vas_cand_ms=1 the age-out
   re-registered and re-logged every pump pass (~480 lines/s) and each
   store memset the learned translation cache. Register once via a new
   'aged_out' flag (reset when a slot is recycled); the candidate stays
   parked for the verified upgrade path.

2. Stale verified VAS on client restart. A client restart rebuilds its
   page directory under the SAME VAS handle (observed X 0x10005:
   pdb 0x12a82f000 -> 0x14b259000). CONT.400's 'never downgrade
   verified' guard then pinned the previous session's directory forever:
   the pump served stale ring/push pages, consumed zero entries and the
   DDX pushbuffer NOP test timed out ('Failed to initialize DMA' /
   'Failed to allocate push buffer'). svc_chan_vas_candidate_promote now
   demotes a verified directory when a parked candidate names a different
   pdb, so the live one can be content-validated and installed.
   Result: X starts reliably and the pump consumes the 2D stream
   (chan_dump 0x1000014: get=1088 sub=1088).

3. Ring-scan starvation. The GR RAM content scan is budgeted to 40
   slices per channel incarnation, and its only re-arm sits at the END of
   the pump loop, which is unreachable because svc_chan_userd() failure
   hits 'continue' first - exactly the unresolved-ring state that needs
   the scan. Re-arm before the USERD probe by reading the raw GP_PUT from
   the registered USERD block and resetting the bounded budget when it
   moves.

Live result: glxgears now reports 529 FPS (was 0.15-0.22 FPS) with
'direct rendering: Yes' and the NVIDIA renderer string; the framebuffer is
still black because the consumed command stream is not executed (see
handoff CONT.401).

0 files changed, 0 insertions, 0 deletions