re(ui): the gamma confound is refuted from source -- canary applies none of its own

I had parked the tone-curve finding behind "this may be the emulator, not
the game: canary applies kernel_display_gamma_type = 2 (BT.709) on
output", with a planned run setting it to 0 and re-fitting. Reading the
source kills both the confound and the experiment.

VdGetCurrentDisplayGamma_entry is a kStub GETTER the guest calls
(xboxkrnl_video.cc). Its own comment: "Used in D3D SetGammaRamp/
SetPWLGamma to adjust the ramp for the display." The cvar is a value
REPORTED TO THE GAME, which then builds its own ramp. Canary's role is
downstream: the guest writes DC_LUT, command_processor.cc reads it into
gamma_ramp_256_entry_table_, and the swap path applies it via
swap_apply_gamma_pipeline_layout with apply_gamma_table.ps /
apply_gamma_pwl.ps compiled in.

So there is no emulator-side BT.709 post-process to subtract, and any
gamma in a captured frame is a ramp the game installed.

What is NOT established, and the reach is stated: that this game installs
a ramp at all, or that the measured 1.34-1.49 is it. The run logs cannot
say -- kernel exports log at Debug and this harness masks Kernel logging
(log_mask = 13, per boot_menu.sh's own comment), so their silence is
guaranteed regardless of what the game did.

The planned experiment was wrong in design: changing the cvar changes
what the GUEST is told and therefore which ramp the GAME builds, so it
could never isolate a stage that does not exist -- and it perturbs the
capture harness, since skip_intro classifies movie-vs-static on an
absolute rmse threshold that a brighter frame biases. The right run
changes nothing about the output: LOG_MASK=12 LOG_LEVEL=3 and look for
the call and the DC_LUT writes.

Also for the port: the ramp depends on the display type the game is told,
and canary hard-codes TV/BT.709 where hardware uses a console setting. So
this is a display profile, not a fixed property of the game.

METHOD: read what a cvar does before building an experiment around it;
and an absence in a log is only evidence if the log would have shown it.

docs/re/REFUTED.md

@@ -482,3 +482,10 @@ neighbourhood, not just the line.
   — but additive noise pushes any such ratio toward 1, and both "native + noise"
   and "bilinear upscale + noise" fit the observed values. The conclusion happens
   to be right; this test does not establish it.
+* "the render-vs-capture gamma may be canary's own BT.709 output transform, since
+  `kernel_display_gamma_type = 2`" → **mine, and refuted from the source.** That
+  cvar is the value a `kStub` getter (`VdGetCurrentDisplayGamma`) hands the
+  **guest**; the game builds its own ramp from it and canary applies the guest's
+  `DC_LUT` ramp in the swap path. No emulator-side gamma post-process exists to
+  subtract. 🟡 Whether this game installs a ramp at all is still unestablished.
+  [`ui-render-tone-curve.md`](structures/ui-render-tone-curve.md)