[RamazanKara]

co-written by Claude Opus 5.5

Split out of #354 so the default-on policy can be evaluated apart from the PyroWave SDK 1.0 move. It doesn't depend on SDK 1.0 and applies on canary as is.

Why

The D3D11 conversion runs on the immediate context, so under a game load it queues behind the game's own submissions. The D3D12 backend converts on its own compute queue, and this makes it the default at HIGH priority.

Changes

• SUNSHINE_EXPERIMENTAL_PYROWAVE_D3D12 becomes SUNSHINE_PYROWAVE_D3D12_CONVERSION, default ON, and sessions request the D3D12 conversion by default.
• The compute queue is created at D3D12_COMMAND_QUEUE_PRIORITY_HIGH, with a logged NORMAL fallback. Realtime is never requested.
• Fallback, decided and logged once per session:
  • RTX HDR sessions and builds without the backend use D3D11.
  • VIBESHINE_PYROWAVE_CONVERSION=d3d11 forces D3D11, with a warning.
  • An unavailable D3D12 device or queue warns with its HRESULT.
  • An unsupported source logs once and stays on D3D11.
  • A submission error still ends the session.
• PyroWave still reads the capture image's own texture and keyed mutex, so the late-join copy-path rule from perf(wgc): encode the helper frame directly and publish it with one copy #347 holds.
• The design doc moves to docs/windows-pyrowave-d3d12-conversion.md. A new test_pyrowave_d3d12_default.py pins the default, the priority, the override and the session-start warning.

Still to qualify on hardware

• D3D12 debug layer clean.
• Plane parity against the D3D11 conversion.
• Repeat detection under load.
• Device loss and teardown.
• Latency and game frame time against VIBESHINE_PYROWAVE_CONVERSION=d3d11 on AMD, NVIDIA and Intel.
• Whether HIGH is honoured beside a GPU-bound game.