[RamazanKara]

co-written by Claude Opus 5.5

This brings Vibepollo#530 to vibeshine canary, rebased onto current canary and reworked after your review there. Vibepollo gets the same change afterwards.

What it does

1. GPU encoders read the WGC helper's shared frame directly (wgc_direct_encoder_input, default on, fixed for each capture session). Each pool image aliases the helper's shared texture through its own duplicated NT handle. The capture thread only claims the newest frame id, and the encoder takes the keyed mutex on its own device, so the host's snapshot copy and one keyed-mutex hand-off per frame are gone. Turning the option off restores the copy path.
2. The helper copies once instead of twice when the host is keeping up. When nothing older is queued or being delivered, the D3D context is free and AcquireSync(0, 0) succeeds, the WGC frame goes straight into the shared texture. Otherwise it takes the scratch handoff as before. The helper diagnostics count direct_published.

Your two review points

• Pixels and timestamps. The conversion reports the frame id and timestamp it actually read under the keyed mutex, and both encode loops use those instead of the claimed ones. A per-encoder-device cursor skips a frame that device already converted, so the same pixels are never encoded twice (two sessions sharing a capture each still get every frame). AMF cancels its reserved input surface on a skip. The choice is one small policy shared by both loops, with unit tests.
• Context lock during the consumer wait. The delivery thread waits for the shared keyed mutex without holding _d3d_context_mutex, then takes the context only if it's free; if the callback is mid-copy it hands the texture back and waits for the context instead. The frame stays in the delivering state throughout, so publication order holds.

New since the Vibepollo PR

• Constant-rate capture (wgcc) and PyroWave keep the copy path. wgcc re-sends its cached image on a timeout, which the cursor would drop. PyroWave needs the capture image's own texture and keyed mutex. Both are latched with the input mode.
• A PyroWave client joining a running direct capture used to receive aliased images. It is now part of the shared capture's configuration, so the existing demand check restarts that capture on the copy path.
• An unreadable frame record (the helper died mid-publish) skips the frame instead of encoding it with the claimed timestamp. It logs at most once a second, and the broken-pipe handling restarts capture.

Tested

RX 7900 XT, Windows 11, native AMF, loopback Moonlight receiver with a barcode strip, 1920x1080 at 120 fps, physical display, direct input on vs off, alternating runs:

• Correctness. Wire order clean in every run of both modes: no backwards, repeated or missing frames, no keyed-mutex timeouts, no helper drops. The same with two clients sharing one capture. 16 launches under a GPU load all started (1.7-2.3 s).
• Host latency. Median about 0.4 ms lower with direct input (HEVC 2.27 vs 2.77 ms, AV1 1.98 vs 2.42 ms).
• Under a GPU load at 60 fps, picture age p95/p99 were equal within noise (direct 28.4/29.8 ms, copy 27.8/29.2 ms). Both modes drop to about 103 fps there. In 13 runs, repeated pictures followed the helper's publish rate the same way in both modes. The PC was shared with other builds, so I only counted runs where CPU stayed under 25%.
• Build and tests. Windows CI-style build with -DBUILD_WERROR=ON; each commit compiles on its own. WGC 29/29, video capture source 14/14, video policy 20/20, web unit 91/91. The remaining ctest failures are identical on plain canary. Linux, macOS and FreeBSD builds are left to CI; the Windows-only code stays behind the existing guards.