vgsp: resolve the completion counter through its real aperture (fb/vidmem) and use it on publish/flush

The X DDX/kick channels' nvPush progress semaphore is a 4 KB sysmem surface
whose GPU mapping resolves to the emulated VIDMEM aperture (va 0x20400ffe0 ->
vidmem pa 0x3f8ffe0), while svc_counter_derive only accepted SVC_APERTURE_SYS
translations; it therefore kept a false guest-RAM pair (a page holding
unrelated data) and svc_counter_publish's put-advance both read and wrote the
wrong page through the SYS aperture - the client's tracker never matched and
the DDX failed 'Failed to initialize DMA' after its 10 s push-buffer sanity
test. Carry the aperture with the registration (new svc_channel.counter_ap,
svc_cnt_der[].ap): accept FB translations in the derive chain (chanvas,
vaspaces, discovered; targeted stays SYS), probe with the found aperture,
keep it through pin override/re-registration; svc_counter_publish and
svc_counter_flush_pending read/write through it (release_pa stays SYS).

Live receipts (c109/c110, 12 GiB guest, params-r1780):
- counter derived h=0x1000013 ... pa=0x211c42fe0 (rank=1) with pub-adv
  writing 14..26 (was silently skipped on a false page in c107);
- the DDX's OWN C36F tracker releases decode and land:
  'sema-push h=0x1000013 va=0x1200a0000 ... rel=0x120001000 pay=1
  have_rel=1' -> 'sema-sw h=0x1000013 va=0x120001000 pa=0x11cc68000 ap=1
  val=0x1 rc=0 rb_ok=1' - the 10 s push-buffer test's exact wait word is
  delivered and the DDX proceeds to further work (values advancing
  0x4017e..0x24024f); previously no release ever decoded.
Remaining X-side flakiness (a later DMA init still failing on some
instances) is tracked in the handoff.

0 files changed, 0 insertions, 0 deletions