test(tui): nothing drawn depends on colour; docs: launch_bounds is not validated

[vyncint]

Milestone 2.2.0, issues #58 and #59.

#58 — measured first, and the issue was wrong twice

The geometry half was already done. The issue claims the suite "runs at one geometry, size(110, 32)". On main it runs nine tests at 80×24, two at 60×30, reaches 110×32 by live resize, and has a_refusal_reason_survives_a_narrow_terminal_whole. #49 changed that after I measured. Corrected on the issue; nothing to do here.

The TUI emits no colour at all. Every style in app.rs is Modifier::BOLD or BOLD | REVERSED; Color:: appears nowhere in the crate; the styles: block of the shipped golden names only bold and reverse. Bold and reverse are SGR attributes, not colour, and NO_COLOR does not ask anyone to drop them. There was no colour-only cue to lose.

So the tests assert the stronger and truer claim:

test	what it holds
no_view_of_the_tui_uses_colour	walks every cell of all four views at 80×24 and asserts fg/bg are the terminal default — structurally, via Cell::style(), not by matching rendered strings
the_metal_banner_keeps_its_emphasis_under_no_color	re-runs the banner assertion under NO_COLOR=1, cell by cell across the whole banner — the cue the issue named
no_color_changes_not_one_cell	styled frames with and without the variable must be byte-identical

The first is the one that earns its keep: the day someone marks a refusal red, it fires and names the cells. Verified by colouring the field heading on purpose —

overview: 24 cell(s) carry colour, which a NO_COLOR reader would lose;
add a cue that survives without it (bold, reverse, or a glyph):
["9:1 fg=Indexed(1) bg=Default", "9:2 fg=Indexed(1) bg=Default", …]

spawn_in_with_env keeps env_clear, so the child sees only what a test names. Sync policy unchanged: one predicate per instant, on view-body content rather than the footer (which names every view on every view).

#59 — the question nothing answered

Does launchbound validate #[launch_bounds] against register limits? No. It never reads a register count, and it does not check #[launch_contract] against grid limits either.

The confusion is earned rather than hypothetical: stencil-1d/kernel.toml opens with "the tuning story is UNROLL × RADIUS × launch_bounds against the register file", lb_max is a real tuning dimension in two kernels, .maxntid is emitted by cuda-oxide, and the tool is called launchbound.

Sharper than the issue put it: the one .maxntid relationship the corpus enforces — exprs = ["block_x <= lb_max"] in stencil-1d — holds because the kernel author wrote it as a constraint and the evaluator does what it is told. launchbound attaches no meaning to lb_max; omit the expression and nothing catches a block larger than its own .maxntid.

A "Not in scope" paragraph in README §What it is, and is not, a matching LIMITATIONS section, each linking to the other — both anchors checked against GitHub's slug rules rather than eyeballed, since a broken link in the sentence that says "we do not do this" is worse than no sentence.

What would close the gap is named so the next reader need not work it out: cargo oxide inspect's PTX already carries .maxntid and register counts. A rule reading them is a new rule with its own measured result and calibration entry — not a documentation change.

just ci green.

Closes #58
Closes #59

Signed-off-by: Vyncint Ng 115854244+vyncint@users.noreply.github.com