re: GPU trace attempt produced nothing -- and the config dump is not the flags

Tried to turn the gamma-ramp inference into a direct observation.
canary's trace_gpu_stream records gamma ramps as their own command type
(kGammaRamp, index 11 in TraceCommandType), so a boot trace should show
the write. Two bounded runs produced NO trace file at all -- nothing under
the prefix, no .xtr anywhere, no scratch/gpu/.

Bounded deliberately: the disk is at 95% (50 GiB free) and a trace of all
GPU packets during boot includes video decode, so the runner carried its
own watchdog that killed the emulator the moment output passed a 2 GiB
cap. It never fired -- there was nothing to cap -- and disk stayed at 95%
throughout. Bounding from inside cost nothing and removed any need to
gamble on how coarsely I could poll.

What the attempt did establish. BeginTracing() runs at GPU init when the
cvar is set (graphics_system.cc:237), but EndTracing() runs only from
GraphicsSystem::Shutdown() -- so the kill -9 this session has used
routinely can never finalise a trace. The second run was stopped with
SIGTERM and exited cleanly; still no file, so that is not the whole
story. Two candidates remain unseparated: the CLI flag not reaching the
cvar, or BeginTracing failing silently. The next run removes the
ambiguity by setting trace_gpu_stream in the config FILE instead.

And a trap I nearly fell into. The startup config dump showed
trace_gpu_stream = false after I passed --trace_gpu_stream=true, which
reads as "flag ignored". It is not evidence either way: the gamma run
passed --log_mask=12 --log_level=3, its dump printed log_mask = 0 and
log_level = 2, and Kernel Debug logging was demonstrably ON -- that run
is where VdGetCurrentDisplayGamma was captured. The dump reflects the
config file and can neither confirm nor refute a command-line override.
(It does not undo the earlier user_language conclusion: absence of a NAME
from the dump still shows a cvar is unregistered.)

The gamma-ramp write therefore remains an inference, unchanged.

docs/re/METHOD.md

@@ -644,3 +644,22 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   which is the one step that could be wrong. Writing that down beside the
   conclusion — rather than only the supporting facts — is what lets a later
   reader attack it instead of inheriting it.
+* **The startup config dump is the config FILE, not the effective flags.** A run
+  passed `--log_mask=12 --log_level=3` and its dump printed `log_mask = 0,
+  log_level = 2` — while Kernel Debug logging was demonstrably on, which is how
+  that run's finding was obtained. So a dump can neither confirm nor refute a
+  command-line override, and reading one as "my flag was ignored" is a mistake I
+  nearly made with `trace_gpu_stream`. Verify a flag by its *effect*, not by the
+  dump. (This does not undo the earlier `user_language` conclusion: absence of a
+  *name* from the dump still shows the cvar is unregistered.)
+* **`kill -9` destroys anything that finalises on shutdown.** Canary starts a GPU
+  trace at init but only closes it in `GraphicsSystem::Shutdown()`, so the hard
+  kills this session used routinely could never have produced a trace. Before
+  concluding a feature is broken, check whether the way you stop the program is
+  what discards its output.
+* **Bound a risky experiment from inside, not by watching it.** A boot-time GPU
+  trace on a disk at 95 % could have filled it between two tool calls. The runner
+  carried its own watchdog that killed the emulator the moment the output passed
+  a 2 GiB cap, so the experiment was safe regardless of how coarsely I polled.
+  The watchdog never fired, which is the point — it cost nothing and removed the
+  need to gamble on timing.