vgsp-gr r604: session-scope the per-VA defer latches; peek the whole channel set incl. eng==0 copy channels

Two fixes, both from the SESSION 49 r603-family capture.

1. The r543 arg-defer latch and the r556 absolute defer cap are keyed by
push VA ALONE, and the UVM pool reuses the same launch push VAs for every
client of a boot - the exact lifetime bug the session flush already fixes
for the r565 exactly-once memories (svc_gr_cap_hist etc.). Carried across
sessions, the r556 stamp armed once at the previous client's first
sighting, so a new client's first decision for a reused VA already read
defer_expired()=true: every partial-argument defer failed closed (r586
path: QMD release authored in software, no engine launch) and the client
read stale/zero buffers. Witness (r603-family boot): the first mail
client (fresh VAs 0x20043be94/0x20043c364) deferred and launched (GUEST
GR LAUNCH OK ok=1/ok=2); every later mail client (VAs
0x20043beac/0x20043c37c reused) saw defer_exp=1 at its FIRST decision
with GR forward REFUSED at defer cap for both launches, and its 'green'
was the previous client's results still in the reused device pages.
Reset both tables with the session; within a session the original
bounds stand unchanged.

2. gsp_phys_gr_peek now logs every drained channel (cap 8 -> 24; the six
CE ranks came first and always spent the cap, so the eng==0
copy-carrying channels were never in the logged set - Session 48's 'the
copy channel's lookahead read empty' was an artifact of that), names the
channel's engine_type, deepens the lookahead to 6 slots, and logs
peek-backlog rows for channels whose live GP_PUT reads ahead of the
pass's consumed position (the r590 watermark skips engine_type==0, so a
published backlog on a GR-class copy channel is invisible to every
existing guard; the capture must show it).

r604 evidence (fresh boot, peek armed, mail first client): both launches
ran (ok=1/ok=2) and green; at the vadd's second decision
'peek-backlog h=0x5c000059 eng=0 put=95 last=94' - the driver's H2D
b-copy entry was already written+published on the eng==0 copy channel
and unconsumed, executed 8 ms after the decision and ~320 ms before the
launch's copy-in; zero write-ahead (+j) rows at any decision.

0 files changed, 0 insertions, 0 deletions