vgsp: m180 VA->PA unification - one landing authority for every data-bearing device VA (kills the write/read translation split of the always-failing class)

Context (r209, fc2d1ae5): multikernel/memcpy_roundtrip/streams2/
victory_streams_events still fail with self-consistent, silent wrongness
while every launch reports OK. Evidence: streams2's bad data is exactly the
PREVIOUS client's h_in pattern (engine read stale inputs); the memcpy
window logs 16x "sema-ledger: DIVERGE read ... wrote=0x7f83000
read=0x8783000" (D2H resolved a different page than the write landed on);
the failing four's device operands are all sysmem-backed (ap=2,
pa=0x7800000/0x8800000 in every svc-gr cand[] line), i.e. exactly the
aperture the m171/m172 ledger never recorded.

Root cause class: a data-bearing guest VA had NO single authoritative PA.
Write paths (H2D svc_copy dst, fills, inline writes, engine write-back)
each landed wherever their own resolution said; read paths (GR launch
fill, D2H svc_copy src) resolved independently again. The ledger patched
up some of that, but (a) it recorded only VID-aperture copies >=64 KiB, so
the dominant sysmem case was invisible; (b) it was a 2048-entry RING -
one launch's submission record set (2505-4553 pages in r209) evicted the
H2D records of the same client before its own D2H read them, so the
readback fell back to its own (different) resolution; (c) several
resolution failures returned -ENOENT even when the landing was known; and
(d) copy paths deferred to the forwarded-request machinery skipped the
in-loop record entirely.

Fix - one landing authority, consulted everywhere:
1. The ledger is now a keyed hash table (16384 slots, 16-probe, one entry
   per VA page, in-place rewrite). No cross-VA eviction: a client's whole
   working set (8 MB in + 8 MB out + engine records) survives until its
   readers have run. Rewrites are counted + logged (bounded) because a
   write path moving an existing page is the write-side half of DIVERGE.
2. Every guest-visible write records its landing page:
   - svc_copy dst_virt: SYS as well as VID (the sysmem half was the hole);
   - svc_fill: SYS as well as VID;
   - svc_grce_inline_write: unconditionally;
   - small copies that are deferred to the forwarded path: recorded at
     candidate capture (the software loop never runs for them);
   - engine launch data pages: unchanged (submission-time record).
3. Every read/write consults it:
   - GR fill: already diverted (m171); now actually has SYS records to
     find;
   - D2H svc_copy src: per-page divert (m171) + NEW fallback to the
     recorded landing when the resolver fails (previously -ENOENT);
   - svc_copy dst / svc_fill / svc_grce_inline_write: NEW - resolve,
     then land on the recorded page when one exists (one page per VA,
     readers already follow it), and fall back to it when resolution
     fails. This also spares the m169 stale-walk hold for destinations
     whose page is already known (no pin needed).

Effect on the failing class: the H2D/fill write landing becomes the page
the engine fill, the copy-out and the D2H all use; where a stale and a
fresh resolution disagree, the readers follow the landing and the other
translation is logged as DIVERGE (read/write) or rewrite - bounded, once.
streams2's c1 (engine read stale) is healed by the new SYS records;
streams2's c2 (readback of an engine output after later launches) is
healed by the hash table, which no longer evicts the first launch's
records.

Zero-write lottery diagnostics (secondary, booter; no behavior change on
the green path):
- content-hash settle rule in gsp_phys_gr_output_retire_wait: the
  "settled" verdict now requires the per-page checksum FOLD to be stable
  for ~300 ms, not just the changed-page COUNT (a continuing store ramp
  with a constant count used to read as settled - the r209 "17/32
  settled"/"2048/4552 settled" partial copy-outs);
- zero-write accept now logs both qmdwin banks' sentinel words
  (ours intact + other bank overwritten = an older deposit was consumed,
  i.e. mis-targeted deposit; ours overwritten = this deposit was fetched)
  and re-scans the tracked pages once at +1 s: LATE-STORES (copy-out will
  ship them) vs NO-STORES (dispatch lost or read-only kernel). The +1 s is
  bounded to the rare zero-write accept path only.
The sentinel constant itself is left intact (it is load-bearing for the
m179 post-mortem classification); the dual-bank read answers the same
mis-targeting question without changing the engine-visible contract.

Untouched on purpose: mm2 publish arm/gate, GR fresh-put rewind, the
release machinery and every semaphore path (no regression surface there).
make kernel -j green (new srcversion); main tree and the running VM were
not touched; nothing pushed.

0 files changed, 0 insertions, 0 deletions