iris bench: a Trace switch for the input/frame diagnostics, and the report says when it was on

`iris::diagnostics::set_trace` landed with nothing to press it. It is the
bench header's fourth control now, reading `Trace off` or `Trace on` --
a toggle whose own appearance never changes is a button that looks like
it did nothing. Its accessibility label stays the fixed "Trace input and
frames", because that is what `run-bench.sh` and `ui-trace --do "tap
'...'"` find it by and a control that renames itself when pressed is one
no script can find twice. Pressing it rebuilds the header and shows the
diagnostics pane, so the state is on screen at the moment of the press.

Both reports carry `trace_line`, from the flag read at the *start* of
what is being reported as well as at the end: the switch is on screen
while a benchmark runs, so "somebody moved it half way through" is a
state that happens, and reported as either "on" or "off" it would be a
confident sentence about a log covering half the run.

The row's type size is one constant for all four labels and drops from
18 to 13: with a fourth control the labels overlapped each other on a
1080px screen. Shrinking one label to fit is what the UI rules forbid;
resizing the row is a layout decision and all four still match.

Checked on the emulator: the switch flips its own text and colour, the
pane reads "input/frame trace: on", and `iris::frame`/`iris::input`
lines appear in the ring only after it is pressed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/RUST.md

@@ -259,11 +259,15 @@ unconditionally `true` by design ("the ring wants everything"), so a
 `log::Level::Debug` line reaches the ring regardless of what this
 instrument would prefer -- the gate has to be a crate-level flag, checked
 before `log::debug!` is even reached, and that is what `trace_enabled()`
-is. **Not wired to a button yet**: the Diagnostics pane that would hold
-the switch is in `iris/android-app/src/bench_client.rs`, which another
-agent had open at the same time this was written; `set_trace` is the whole
-surface a control needs, so wiring one is a follow-up for whoever is free
-to touch that file next.
+is. **The switch is the bench header's fourth control**, beside Run
+benchmark / Copy report / Diagnostics: it reads `Trace off` or `Trace on`,
+because a toggle whose own appearance never changes is a button that looks
+like it did nothing. Its accessibility label stays the fixed `Trace input
+and frames` -- that is what `run-bench.sh` and `ui-trace --do "tap '...'"`
+find it by, and a control that renames itself when pressed is one no
+script can find twice. Pressing it rebuilds the header (the same
+`bench_controls` path `on_insets_changed` already uses) and shows the
+diagnostics pane, so the state is on screen at the moment of the press.
 
 **Why default off, and why the ring's size is the actual constraint**: the
 ring is 2000 lines / 256 KiB
@@ -273,8 +277,12 @@ seconds, so a caller turns tracing on only for the length of whatever is
 being investigated, not for a whole session. This is also why the report
 should say at its top whether tracing was on -- a caller reading
 `iris::diagnostics::trace_enabled()` when building the report can print
-that; nothing here does it automatically since nothing here owns the
-report's own header.
+that. Both reports do: `bench_client::trace_line` is the one wording, and
+it takes the flag **read at the start of the run as well as at the end**,
+so a switch flipped half way through is reported as exactly that rather
+than as a confident "on" about a log covering half the run. Three states,
+because that third one happens -- the switch is on screen while a
+benchmark runs.
 
 **D1 from `docs/REVIEW-2026-09-07.md`**: the review found that this gate
 existed (as `iris/src/diagnostics.rs`, uncommitted at the time) but four