Add the Helix LT, measured against a physical unit

[pakdekro]

The Helix LT enumerates as 0x0E41/0x424A, which neither the device table nor the udev rule
covered — so Transport::open never saw it and its raw USB node stayed root-owned. Adding the PID
was the only change needed: the handshake, the preset read, the snapshot decode and both browses
work unmodified, and the catalogue resolved every block and parameter of the loaded preset by name.

Everything in the new entry was read off the device, not inherited from the Floor:

field	how it was established
model_code: Some("P21")	handshake identity reply; the pulled preset agrees at key 7 → 36
dsps: Some(2)	preset key 1 populated, blocks in slots 21–28 (DSP1 71.0% / DSP2 43.0%)
snapshots: Some(8)	the preset carries SNAPSHOT 1…SNAPSHOT 8
setlist_size: Some(128)	banks 0–7 each list 128 presets; bank 8 refused with code -3
preset_device_id: None	not observed — no 0x0021xxxx id on the wire, and no LT .hxb to read one from

The one place the evidence is thinner than the Floor's: the setlist names are the Floor's. Only
the arity and the character of the two end banks were observed (bank 0 = factory amps, bank 7 =
Quick Start / Parallel Spans / SNP:4-Amp Spill), whereas the Floor's names came from a real
.hxb. docs/helix-lt.md says so explicitly, and flags it as the field to fix if an LT backup
ever turns up.

It stays Support::Untested: no edit has ever been sent to this unit — reads and the handshake
only, per docs/safety.md's "read-only / transient first".

Also renames the_untested_device_claims_nothing_it_hasnt_shown_us to name the Stomp XL, since
"the untested device" is no longer singular. It still asserts exactly what it did before.

cargo fmt --all --check, cargo clippy --locked --all-targets … -- -D warnings and
cargo test --locked all pass locally on the offline crates (rustc 1.97.1). The GUI job wasn't
run.

Happy to gather more from the unit if useful — it's on hand. In particular, a fretwire backup
sweep would settle the setlist names, and I'm glad to run one if you'd like it in the docs.

_{Built and tested on NixOS; the device was reached through a local package of fretwire with this
patch applied.}

[john-baxter-dev]

Thanks for this — a measured survey from real hardware is exactly what the
device table needs, and the reads-only discipline (Support::Untested,
preset_device_id: None rather than copying the Floor's) is right.

Three questions on docs/helix-lt.md before I merge. All are about pinning
down what the unit actually showed you, since I don't have an LT and can't
check any of it myself.

1. Block count — how many, and in which slots? (lines 56 and 61)

Line 56 says blocks came back "in slots 21–28 as well as 3–6", which is 12
slots (DSP0 index 3–6, DSP1 index 1–8). Line 61 says "every one of the 8
blocks resolved". The DEVICES comment in lib.rs then repeats only the
21..28 half.

Which is right, 8 blocks or 12? And does the "8" perhaps count only the
DSP1 group? It's a [solid]-tagged section and it's the evidence dsps: Some(2) rests on, so I'd like the slot list exact.

2. Banks 3–5 — browsed, or not? (line 66)

The table is introduced as "browsing each bank in turn" but lists 0, 1, 2, 6,
7 and 8. To be clear, I don't think this threatens the conclusion — bank 8
refusing with code -3 bounds the arity at 8 on its own. It's just that as
written a reader can't tell whether three rows got dropped in editing or
whether 3–5 weren't browsed. Either answer is fine, I'd just like the table
to say which.

3. The setlist_stride() fallback sentence. (line 78)

Line 5 says the survey ran "with this PR's device entry applied", and that
entry sets setlist_size: Some(128) — so unwrap_or(128) would never have
executed. Did you run the browses before adding the entry? If not, I think
the sentence just wants to say the measurement corroborates the explicit
value rather than the fallback.