test_apps: cube_handle_d3d12_win is washed out on the rig (double sRGB encode in the app's colour path) #1882

Seen by David on the two-panel win rig (2026-10-09, runtime main after #1879, Leia plug-in #323 build, LeiaSR 1.38.0+2255): cube_handle_d3d12_win looks washed out (low contrast, lifted blacks) on the laptop panel and on the DS1, on the single-DP path (window fully on one panel) as well as when it straddles the seam (per-segment path). cube_handle_d3d11_win on the same runtime, same plug-in, same panels looks right, so it is not the panel or the weaver.

Evidence from the runtime log: the app picks DXGI_FORMAT_B8G8R8A8_UNORM_SRGB (29) for its swapchain (PickPanelFormat), the compositor logs Color (#1589) [d3d12]: format-honest — _SRGB sources decode on sample …, the DP output format is 28 (UNORM back buffer). That is the same contract the D3D11 cube runs under, so the difference is in how the D3D12 app writes its pixels. The D3D12 app got the display-referred clear helper in #1679, but David's suspicion is that the rest of its colour path was never brought up to INV-4.6 the way the demos were (ADR-044): one of the writes is encoding twice (sRGB bytes written through an _SRGB RTV, or a pow in the shader on top of the sRGB view).

To do: diff the D3D12 cube's render path (RTV format on the _SRGB image, shader output, the Local2D placed-footprint upload at main.cpp ~L515 which must stay a raw copy of display-referred bytes) against the D3D11 cube's, fix the double encode, and re-check by eye on the rig. Lint with scripts/check_displayxr_app.py.

Not a regression of the multi-screen work: the per-segment crop is a raw CopyTextureRegion in the atlas format with a UNORM-sampled SRV, and the single-DP path shows the same look.