feat(nr-alq): --trace/--trace-cpu say that release builds trace CPU interrupts only

[rmstdope]

Bead: nr-alq (no GitHub issue).

--trace / --trace-cpu print NES instruction lines only in debug builds. Per the agreed variant C:

• Both help lines now read Enable CPU trace output (instructions only in debug builds), in every build.
• A release build started with either spelling prints one line on stderr before any trace output:
  warning: <flag>: this release build prints CPU interrupts only; build without --release for instruction lines,
  naming the first spelling typed. Debug builds and runs without the flag are unchanged. The trace output itself is unchanged.

The decision lives in a pure platform::debugging::release_cpu_trace_warning(args, debug_build); main.rs passes cfg!(debug_assertions) and prints it just before init_tracing, which runs after --help/--version return and before both the headless and windowed paths.

Validation

• ./scripts/test-dir.sh src/platform: all pass, including the 8 new tests.
• Release --help: both entries show the new line under "Trace and Debugging"; --help --trace-cpu prints no warning.
• Release headless --trace-cpu, --trace, --trace-cpu=2: exactly one warning line, first on stderr, none on stdout. --trace --trace-cpu names --trace; --trace-cpu --trace names --trace-cpu. No flag: no warning.
• Debug headless --trace-cpu: no warning.
• ./scripts/gate-full.sh: passed.

No deviation from the plan.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HqUacMKowXnUgZnfLFn8YT

[rmstdope]

Review (cold read, reviewed_head: 6a562a22e02fc4238db1d0c4d58b7f817b1c4b61) — reviewed before merge under the producer's review practice, by an agent given the diff and the bead, and not the producer's reasoning.

1. Blocking, needs a decision: the agreed claim is false for SNES and GB/GBC ROMs. --trace/--trace-cpu also drive the SNES and SM83 cores. Their instruction traces are not under #[cfg(debug_assertions)] (src/snes/cpu/cpu.rs:891-893, src/gb/cpu/sm83.rs:742-760, plus level-2 bus lines at snes/cpu/cpu.rs:3926-3931 and gb/cpu/sm83.rs:239-267). So target/release/neser --headless --trace-cpu=2 game.sfc, the bus-trace workflow architecture.md:105 documents, prints the full trace and opens with "this release build prints CPU interrupts only; build without --release for instruction lines". The help line "(instructions only in debug builds)" is equally wrong for those cores. The text is agreed verbatim, so the navigator or UX should decide: NES-specific wording, suppressing the warning for non-NES ROMs, or accepting the mismatch.
2. Same decision: "interrupts only" is untrue for the NES at level ≥ 2. A release --trace-cpu=2 prints the ungated [CPU] tick … [read]/[write]/[internal] lines (src/nes/cpu/cpu/bus.rs:17,27,57,69, src/nes/cpu/cpu/timing.rs:26,35).
3. Suggestion: for --trace-cpu=0 --trace, the warning names --trace-cpu, although --trace is what enabled the trace. Skipping the =0 forms in find_map would fix it.

[rmstdope]

Producer's answers to the review

1. Confirmed in the code: the SNES and SM83 instruction traces print in release builds. This is a wording/state decision the agreed experience does not settle, so the bead goes back to the UX stage with this question. The PR stays open until it is answered.
2. Confirmed. Sent to the UX stage together with 1, since it changes the same warning text.
3. Agreed. I'll make the change once the wording is settled, so the warning names the spelling that actually enabled the trace. Holding it now, because the answer to 1 may reshape this function.

[rmstdope]

Superseded by #3340: the wording was sent back to UX and re-agreed (NES-only, warn at the first NES game).