vgsp-sema r539: pool release fan-out to a second candidate page + STALL-DUMP watchdog

The init-stall boots (r530-r538) share one shape: the pump loops but the
entry loop stops consuming, and a client spins in uvm channel_pool_add ->
uvm_push_end_and_wait while its pool tracker word is frozen. The r538 live
boot showed the cause live: va=0x121000000 flapped between the injected pin
(the guest kernel's tracker->page->rm_mem chain) and the host GMMU walk on
every resolve (pool-boot conflict ping-pong, ~50/s), and the release write
follows whichever source answered that pass - a release written to the
losing page strands the client that polls the other one.

Fix: svc_pool_boot_store keeps BOTH most-recent distinct pages (primary +
secondary, each with its own proof stamp). svc_pool_boot_fanout applies
every successful pool release to the secondary as well (forward-only,
read-back proven, 10 s freshness so a freed/reused page is never written).
Wired into all three svc_sem_write success paths and svc_fake_release's
recovery write. The r536 walk-over-pin preference stays as the primary
choice; the pin is now recorded as the secondary there.

Also: STALL-DUMP - when the entry loop consumes no entry for 20 s while
withheld work exists (pending releases or opdef slots), dump the pending
list, opdef slots, pool candidates and counters once (bounded 4/boot), so
the next stall is named in one place instead of N bounded logs.

0 files changed, 0 insertions, 0 deletions