vgsp: cross-class FB ring-block claims stop the GR autopin stealing a live foreign ring

The GR ring autopin fallback (SESSION 133c userd-shape scan) and the CE
first-submission capture each guarded block ownership only within their own
engine class, so a channel whose own ring was not yet written latched another
channel's live block permanently: the GR channels drained the CE rank-0 ring
(or an unlatched CE rank's convention block), the real launch entry was never
read, and CUDA clients hung after their first device query (victory_mail
stalled in UVM channel_pool_add; every post-reboot boot r805-r811 showed the
same steal, e.g. 'auto-pinned GR ring h=0x5c000019 rank=0 ... -> fb 0x80000
(userd-shape scan ... entry0 va=0x120000000 len=40 put=35 get=35)' while the
CE handle decoded the identical entry[35] raw words from pa=0x10350641c).

Changes:
- shared FB block claim table (svc_fb_claim_add/_foreign/_reset), session
  scoped, consulted by both GR scan passes and the CE fallback scan; every
  live CE rank's convention block is reserved even before that rank latches
  (r809: CE rank 1's block at fb 0xa0000 was stolen pre-latch);
- every GR autopin latch (userd-derived, FB convention, pin, trusted walk,
  scan pass 1/2) and both CE latch paths record claims;
- CE first-submission capture: a rank's own convention block is latched even
  when its stale content probes incoherent (the previous session's consumed
  state), instead of falling through to a never-used zero block (r812/r813:
  client 2's 0x90000 block read put=1/get=146 at the capture instant and the
  zero 0x82000 block was latched, hanging the client).

No module parameters or defaults change; the guards are additive.

Validated (plain mdev, script defaults):
- victory_mail GREEN repeatedly: 'VADD n=32768 bad=0 checksum=12204516.000000'
  / 'STATUS OK', all six GR ranks latched at their own fb 0x140000+0x3000*rank
  rings with 'launch captured h=0x5c000019 push=0x20043be94 len=840';
- a second sequential client on the same boot now progresses (vecadd_loop:
  'VERIFY launch=10 bad=0' - the 100-launch loop needs a long budget).

0 files changed, 0 insertions, 0 deletions