re: the GPU trace is compiled out of the release build -- both my guesses wrong

Last iteration left two candidates for why trace_gpu_stream produced no
file: the CLI flag not reaching the cvar, or BeginTracing failing
silently. Neither. Following the code instead of guessing:

BeginTracing only sets trace_state_ = kStreaming ("Streaming starts on
the next primary buffer execute"). The file is opened later, in
ExecutePrimaryBuffer, inside

  #if XE_ENABLE_TRACE_WRITER_INSTRUMENTATION == 1

and trace_writer.h defines that as 0 under NDEBUG, 1 otherwise -- the
trace writer exists only in debug builds.

Confirmed against the binaries, with a control. The format string
"{:08X}_stream.xtr" lives only inside that guard:

  build/bin/Linux/Release/xenia_canary          0 occurrences
  build/bin/Linux/Debug/xenia_canary            1 occurrence
  /sylph-home/re/canary-build/.../Release/...   0   <- what run-canary uses

The debug binary is the control: it proves the test finds the string when
it is present, so the release zero means something.

So trace_gpu_stream is a no-op in this container's emulator -- the cvar
parses, BeginTracing runs, and nothing can open a file. The kill -9 was
not the cause either, though it would have destroyed a trace had one
existed.

The route exists but is not cheap: a debug build with the writer compiled
in sits at build/bin/Linux/Debug/xenia_canary, 253 MB against Release's
18 MB, so a much slower boot plus a trace of every GPU packet on a disk
at 95%. Recorded as available rather than attempted -- what it would
confirm, the DC_LUT write, is already a well-supported inference, and the
cost is out of proportion to the gain.

METHOD: a cvar existing does not mean the feature is compiled in; and
test a compile-time gate against the binary, with a control.

docs/re/METHOD.md

@@ -663,3 +663,15 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   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.
+* **A cvar existing does not mean the feature is compiled in.** `trace_gpu_stream`
+  parses, is documented, sets state, and does nothing: the code that opens the
+  trace sits behind `#if XE_ENABLE_TRACE_WRITER_INSTRUMENTATION == 1`, which
+  `trace_writer.h` ties to `#ifdef NDEBUG` — off in release. Two runs and two
+  wrong hypotheses before reading the `#if`. When a switch produces no effect,
+  follow the code from the switch to the output and look for a compile-time gate
+  before theorising about runtime causes.
+* **Test a compile-time gate against the binary, with a control.** A string that
+  exists only inside the guarded block (`_stream.xtr`) settles it in one command:
+  0 occurrences in the release binary, **1** in the debug binary. The debug build
+  is the control that proves the test can find the string when it is there —
+  without it, "0 occurrences" is just as consistent with a bad grep.