guest-diag: demand pinning for stalled CE VAs (event-independent hole filler)

The one-shot #sem kprobe event that drives the CE push-buffer chain
resolution can be lost (trace rotation, scanner restart, slab kptr reuse),
and the chain resolver then never learns a client - every GPFIFO entry of
its CE channels is grace-skipped and the client spins on its tracker
semaphore (the copy-heavy stall class: streams2/memcpy/multikernel/saxpy
in r148; smiley as a later client in r147 took ~90 s to recover).

New demand channel, both ends here:
- pin_gr_stream: _demand_loop scans the host dmesg for 'stalled VA #N:
  0x...' (the service logs each distinct unreadable push VA once), tracks
  each sighting, and re-sends every 20 s for up to 5 min to
  /tmp/guest_want_vas.txt in the guest (via the guest agent).
- guest_pin_stream: the main loop reads new VAs from that file and resolves
  each by CONTENT against the nv_vm_map_pages vmap areas
  (resolve_va_by_content: candidate leaf page at the VA's in-window offset,
  +1/-1 neighbours for the header-page offset ambiguity, host-plausible
  method-stream prefix). On a match the exact pair is emitted; only the
  requested VA is pinned, so a wrong candidate cannot poison other VAs.

Also fix the scanner start: the kill-first pattern must be anchored
(^python3 /tmp/guest_pin_...) - the unanchored pattern matched the deploy
shell's own cmdline and every start attempt killed its own shell before
launching the scanner (r149: no scanner for the whole boot).

0 files changed, 0 insertions, 0 deletions