Global Settings: populate settings for "Footswitches", "EXP Pedals", "MIDI/Tempo", and "Displays"

[rtsai]

Decoded on an HX Stomp XL using the following procedure:

Setup:

cargo run -p fretwire-cli -- settings-dump > base.txt

Iterate:

• Change one of the settings
• Run the following commands to see what changed:

cargo run -p fretwire-cli -- settings-dump > changed.txt
diff base.txt changed.txt

Also, update spellings to match what is shown in the HX Stomp XL Global Settings UI:

• "MIDI base channel" => "MIDI Base Channel"
• "MIDI over USB" => "USB MIDI"
• "Tempo select" => Tempo Select"
• "Tempo" => "BPM"

[john-baxter-dev]

Merged, thank you! This is the largest single contribution the settings table has had — 34 ids to 53, and both
of the sections that had been declared-and-empty since I read the menu headings off the hardware are
now populated. The paragraph in GROUPS explaining why they were empty is gone, and a test
(every_declared_group_has_rows) keeps them that way.

Thanks for correcting the names to exactly what's on the pedal, too. That was me being sloppy :p

Four follow-ups in 397c3e7, none of them changes to your entries:

Kind::Flag vs Kind::Choice. You have 117/135 as two-option choices next to 10/25/26/129
as flags, which is right — it is the wire type, not a style — but nothing in the file said so, and
that is exactly the distinction PR #14 corrected. I put a note on Kind itself so the next reader
doesn't tidy the mixture into consistency. Worth knowing for anything you write later: it only
affects how the panel draws the row. set_setting_num reads the current value and matches its type
before writing, so a mislabel can't send a wrong-typed write.

135 has no place in MENU_ORDER. Everything else in MIDI/Tempo got placed. Rows sort by
(group_rank, menu_rank, id), so it draws at the foot of its own section rather than anywhere wrong
— I left it there rather than guess a position, and added only_the_listed_ids_are_unplaced so the
next id that arrives without one fails a test instead of quietly sorting last. If you have the pedal
in front of you, its row number in the MIDI/Tempo menu is the whole fix.

The mock had drifted. ui/src/mock/backend.js keeps its own copy of the table for npm run dev,
and it still listed id 12 in the unidentified tier — an id you just named. All 19 are mirrored
now, so the two new sections actually render in the browser mock.

_TODO-settings-discovery.md is retired, answered. Three things it asked for came back
unanswered and moved to the bottom of _TODO-settings-names.md.

One question, and one thing I'd like on the XL if you have the time:

129 TAP Function as a two-state flag. Its two labels, AllBypas and TAP/Tunr, are two of
the ten that 130/131 offer. If the TAP switch offers the same menu and you happened to toggle
between two of them, a Flag locks the rest out. Did you cycle it?

My action item: Do any of these refuse on a Stomp? All 19 exist on an XL's word alone. 130/131 are
FS7 Function/FS8 Function and a Stomp has three switches, so at least those two ought to refuse
— but that is reasoning, not an observation, and a refusal is a real result here: scan_settings
reads it as absence rather than an error, which is what lets one table serve both pedals. That one
needs a Stomp, so it's mine to do, not yours.

[rtsai]

129 TAP Function as a two-state flag. Its two labels, AllBypas and TAP/Tunr, are two of
the ten that 130/131 offer. If the TAP switch offers the same menu and you happened to toggle
between two of them, a Flag locks the rest out. Did you cycle it?

I'm not sure what you are asking about here. On my HX, the "TAP Function" only offers two choices; turning the encoder knob to the left offers "TAP/Tunr" (false), and turning the encoder knob one click to the right offers "AllBypas" (true). There are no other choices.

And the chosen setting for 129 (TAP Function) does not affect what is offered for 130 (FS7 Function) or 131 (FS8 Function).