feat(nr-alq): a release build says --trace/--trace-cpu prints no NES instruction lines

[rmstdope]

Bead: nr-alq (Forge refactoring; no GitHub issue). Supersedes #3336, whose wording was sent back to UX (false for SNES/GB and NES level 2) and re-agreed as option B.

What changes

• --help: --trace and --trace-cpu read "Enable CPU trace output (NES instructions only in debug builds)".
• A release build started with --trace/--trace-cpu prints, once per run, on stderr, as the run's first NES game starts (CLI or browser), before any of its trace lines:
  warning: <flag>: this release build prints no NES instruction lines; build without --release for them
  SNES / GB / GBA games get none; the spelling named is the one that turned the trace on.
• How: platform::debugging::release_nes_trace_warning(args, debug_build) builds the text in main; AppContext holds it; rom_loader::build_nes_console (the one load path of headless and windowed runs) takes and prints it after the cartridge parses.

Validation (the plan's, all passed)

• ./scripts/test-dir.sh src/platform: 664 passed.
• Release --headless --frames 1, on palette.nes: --trace-cpu → one warning naming --trace-cpu; --trace → --trace; --trace --trace-cpu → one line, --trace; --trace-cpu=0 --trace → --trace; --trace-cpu=0 and no flag → none; nothing on stdout.
• Release --trace-cpu=2 on a .sfc and a .gb ROM → no warning. Debug build --trace-cpu on NES → no warning.
• --help shows the agreed line on both entries; --help --trace-cpu prints no warning.
• ./scripts/gate-full.sh: passed.
• Left for verification (human): windowed release run with --trace-cpu, open an SNES game (no warning), then an NES game (one), then another NES game (none).

No deviation from the plan.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MnkhMKupMHwCLcHBCKtE4W

[rmstdope]

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

The help line and warning text match the agreed wording exactly. The flag the warning names is the one that turned the trace on. --help exits before the warning is set. load_console is the only load path, for headless runs, a ROM on the command line and the browser. SNES, GB and GBA games, and NES files that fail to load, leave the warning pending; it prints before Console::new_nes. switch_to_cartridge runs only on an NES console that has already taken the warning. All 12 new tests pass, and each failed without the change.

1. src/platform/debugging/tracing.rs release_nes_trace_warning duplicates Tracing::apply_args's CPU-level parsing; a future spelling/level rule could drift silently. Suggest a shared helper or a consistency test.
2. architecture.md: the row edited names src/debugging/tracing.rs (does not exist; it is src/platform/debugging/tracing.rs, pre-existing error); the src/platform/rom_loader.rs row could mention the warning.
3. src/main.rs wiring is untested by unit tests; covered by the PR's manual release-binary checks, proportionate. Windowed SNES→NES→NES remains for the verifier.

[rmstdope]

Answers to the review, at d9e3159bb6451182f44eff9fef1f6c0d0aaaf4d5:

1. Fixed. Tracing::cpu_level_from_arg is now the one reader of --trace / --trace-cpu[=N], used by both apply_args and release_nes_trace_warning, so they cannot drift apart. The existing apply_args tests and the new warning tests pass.
2. Fixed. The four src/debugging/ rows now say src/platform/debugging/, and the src/platform/rom_loader.rs row mentions the warning.
3. No change. The wiring is a single line in main, and the release and debug binary checks in the PR body cover it. The windowed SNES → NES → NES check is left to verification.

No follow-up review: the change is a mechanical extraction that keeps behaviour as it was, plus doc paths.