The round-4 residuals, closed after the WP-D hardware verdict:
- VUI colour plumbing (the one silent-wrong): the picture's ACTIVE SPS's
colour signalling (H.273 code points + range, with E.2.1's 'unspecified'
inference where the VUI is silent — the vendored parser's defaults ARE the
inferred values, verified) rides PicturePlan -> DecodedVkFrame ->
NativeVkFrame per frame, never latched: the Windows host switches an HDR
desktop to PQ/BT.2020 IN-BAND while the Welcome still says SDR. Before
this, the native path would have painted PQ washed out, silently.
- Native decode-latency stat: the deliberately-deferred NativeVk arm of the
pump's sampled once-per-stats-window decode measurement now feeds - the
frame's (semaphore, semaphore_value) is the decode-done signal, resolved
through the shipped ledger before a bounded, pure-measurement
vkWaitSemaphores (VkH264Decoder::wait_decoded).
- The renegotiation-teardown window is settled as NO HOLE: rebuild_state now
documents the full safety argument (graveyarded pools stay intact under
presenter holds, tokens route strictly by generation, session objects die
only post-drain with the generation gate INSIDE read_status), and the two
backend comments that wrongly claimed stale pools were 'gone' are fixed.
- VK_KHR_unified_image_layouts stays deferred (fleet drivers lack it).
Adversarial review round 6: 3 minor findings (2 doc fixes applied; the
SPS-replaced-without-PPS-resend divergence stays a documented envelope
assumption - hosts re-send both at every keyframe, and a hardening
PlanWarning could cost real frames on a false positive).
Gates: fmt clean; clippy -D warnings zero (mac + pf-lxcheck2 container,
incl. pf-client-core/pf-presenter); tests 45+30+53 mac, 30+121+53 container.