Make Ctrl+/ resolve the same on every terminal, not just kitty

[sinelaw]

Fixes #2933

The bug

A terminal without the kitty keyboard protocol has one byte for this chord: it sends 0x1F for Ctrl+/, Ctrl+7 and Ctrl+_ alike. byte_to_keycode derived the whole 0x1C..=0x1F range arithmetically onto \ ] ^ _, so the byte came out as Ctrl+_ — which no keymap binds.

Under kitty the same chord arrives as CSI 47;5u and decodes straight to Ctrl+/, which is exactly why ctrl+/ (toggle-comment in the default keymap, undo in the emacs one) worked there and nowhere else.

The fix

Parser — 0x1F now reports as Ctrl+/: the key people actually press for it, and the one a kitty terminal already reports, so both kinds of terminal resolve to the same binding.

0x1C/0x1D/0x1E deliberately keep \, ], ^. Those are the keys bound to them today (ctrl+] is goto-matching-bracket, ctrl+\ is toggle-keyboard-capture in the macOS keymap), so re-canonicalising them would break working chords. 0x1F was the only one of the four whose spelling was wrong.

PTY — control_byte had no / arm, so Ctrl+/ aimed at a terminal panel fell through to the plain-character path and the child saw a literal / (repro C in #2933). Already wrong under kitty; would have become universal once the parser reports the chord this way.

That's the whole change: two source lines plus their tests.

Verification

Every test was checked to fail without its fix, by reverting each hunk in isolation:

layer	without the fix
parser (0x1F → Ctrl+/, legacy/kitty agreement)	FAILED
PTY (chord reaches the child as 0x1F)	FAILED — [47] (/) vs [31]
e2e (raw bytes in, rendered screen out)	FAILED — both legacy-byte tests; the kitty control still passed

The e2e tests drive the raw bytes a real terminal sends through InputParser into the harness and assert on rendered output (CONTRIBUTING #2), following csi_u_session_input.rs. other_separator_bytes_keep_their_keys passes either way by design and is labelled a characterization test — it pins 0x1C–0x1E against future churn.

Also verified by hand in tmux against a running editor: raw 0x1F toggles the comment and round-trips, and ESC [ 47;5u does the same.

What this PR deliberately does not touch

An earlier revision of this branch also reworked terminal_key_equivalents and added an input.key_aliases config table to make the aliasing tunable. That's been dropped.

The alias table existed because the parser used to report this byte as something no keymap binds (Ctrl+7 in the crossterm era, Ctrl+_ after the rewrite), so an alias was the only thing making ctrl+/ resolve. Canonicalising the parser on the spelling keymaps actually use removes that need. A scan of all five shipped keymaps found only two bindings spelled with an alternate form, and neither benefits: default.json's ctrl+shift+7 can't be encoded distinctly on a legacy terminal and matches directly on kitty, and macos.json's ctrl+- matches directly on kitty too.

The one open question is whether macOS terminals really emit 0x1F for Ctrl+-, which I could not find a source for. If they do, the fix is one explicit line in macos.json rather than a configurable alias layer.