vgsp-sema: synchronize the session flush with channel registration; stop sleeping in the VA-space walker (ISSUE-0002)

Two host-side defects from the r9 capture:

1. The session-end flush was executed at the top of svc_rebuild without
   checking whether the next session had already started registering:
   in r9 it ran between the second client's first and later channel
   registrations and wiped its freshly learned state mid-setup. The
   flush now runs on svc_thread only (the sole writer of the discovery
   state), at the top of its loop; a first channel of a new session
   waits on svc_sess_flush_done before registering, so the wipe can
   never land after that session's state exists and the new session
   still starts from a clean slate. Scans abort on the pending flag so
   the wait is bounded, and channel_del wakes svc_thread so the flush
   runs promptly instead of waiting out a pass.

2. svc_walk_vaspaces held svc.vas_lock (spinlock) across svc_gmmu_walk,
   whose guest reads go through vfio_dma_rw (mutex, may sleep) - the
   'BUG: scheduling while atomic' in the r9 service log. The walker now
   snapshots the published VA spaces under the lock and walks unlocked.

0 files changed, 0 insertions, 0 deletions