fix(terminal): name the selection colour the way xterm 6 does

[Ark0N]

Part of #360, and the part that is demonstrable without an Android device.

The bug

Every per-skin xterm palette in terminal-ui.js declared its selection layer as selection. xterm.js renamed that key to selectionBackground in v5, and this repo is on @xterm/xterm ^6. An ITheme is a plain object handed straight to the terminal, so an unknown key is not an error, it is dropped: all seven skins have been painting xterm's built-in default, rgba(255, 255, 255, 0.3), instead of the colour sitting next to it in the palette.

On the dark skins nobody noticed, because white at 30% is roughly what those palettes asked for anyway. On the four light skins it is white over a near-white background. Blended the way xterm does it (selectionBackgroundOpaque = blend(background, selection)):

skin	background	painted before	delta	painted after	delta
Paper Gray	#f6f8fa	#f9fafc	3	#c7dbf4	47
Solarized Light	#fdf6e3	#fef9eb	8	#d2e1e0	43
Catppuccin Latte	#eff1f5	#f4f5f8	5	#c9d8f5	38
Rosé Pine Dawn	#faf4ed	#fcf7f2	5	#d0d8d8	42

A three-to-eight-in-255 highlight is not a subtle highlight, it is no highlight, and it is indistinguishable from a selection gesture that failed. That is one of the things #360 describes on Android Chrome, and it applies to desktop drag-select on those skins too.

The fix

Rename the key in all seven palettes. Nothing reads .selection anywhere in the codebase (the theme object is passed wholesale to xterm by applyTerminalSkin() and by the teammate terminals in panels-ui.js), so the rename is the whole change.

test/skin-themes.test.ts pins both halves, because a rename that fixed nothing would pass a name-only assertion:

• no palette carries the legacy selection: key, and every palette declares selectionBackground;
• the blended selection stays at least 16/255 from its own background on every skin;
• on the light skins, xterm's fallback lands under that floor, which is what makes this a fix and not housekeeping.

Verified failing on master and passing here.

What this does not fix

The main symptom in #360, the terminal going blank on long-press on Android Chrome, is separate and is not addressed here. I have asked on the issue for the one diagnostic that would narrow it (whether ?nowebgl changes the behaviour), since a blanked viewport under WebGL points somewhere quite different from a lost selection.

[Ark0N]

Merged, and shipping in 1.29.0: https://github.com/Ark0N/Codeman/releases/tag/codeman@1.29.0. Worth noting that #375 carried the same rename as one of its 27 commits (cd1114cf); that one is superseded by this, and the rest of #375 is being landed separately.