Fix invisible selection color when a theme has no [colors.selection]

[perryqh]

Screenshots

Before — theme with no [colors.selection]: selection background equals the foreground color, so selected text is nearly unreadable.

After — falls back to color8 instead, so the selection is clearly visible.

Summary

• omarchy-theme-colors-from-alacritty fell back to foreground for selection_background when a theme's alacritty.toml had no [colors.selection] block, making selections/highlights identical to text color and effectively invisible (Neovim visual mode, gum confirm/choose prompts, btop's selected row). Now falls back to color8 (bright black, itself falling back to normal black), matching the fallback chain omarchy-theme-color already uses elsewhere.
• omarchy-theme-set now also repairs that same fingerprint on the staged copy when an extra/git theme's repo already committed a colors.toml carrying it — theme-set skips regeneration once colors.toml exists, so such a theme would otherwise recopy the stale value forever no matter how many times it's refreshed. Only the staged copy is rewritten; the user's own theme source (which may be a git clone or a symlink into personal dotfiles) is left untouched, so the repair harmlessly repeats on every switch of an affected theme.
• Adds a migration so a theme already active before this fix gets refreshed automatically on next update. It also guards against a current theme that was later deleted: blindly refreshing it would hit omarchy-theme-set's "Theme does not exist" and hard-fail under omarchy-migrate's set -euo pipefail, stalling every migration queued behind it — so it seeds "Tokyo Night" instead, mirroring the existing 1787481315.sh migration.

Fixes #9266

Test plan

• test/cli: a theme with [colors.bright] but no [colors.selection], and one with neither, never get selection == foreground in the generated colors.toml
• test/shell.d/theme-staging-test.sh: an extra/git theme with a baked-in stale colors.toml is repaired to color8 (falling back to color0) on the staged copy, with the source left untouched; a healthy or official palette is never rewritten
• test/shell.d/theme-selection-color-migration-test.sh: the migration refreshes an affected theme, leaves a healthy one alone, no-ops with no current theme, and — run against the real omarchy-migrate — does not stall the migration queue when the current theme was removed or theme.name is missing
• ./test/cli and ./test/shell pass
• ./test/all shows no new failures (4 pre-existing failures on quattro unrelated to this change, reproduced independently with these commits removed: config-test.sh, snapper-test.sh, theme-install-guards-test.sh, unowned-system-paths-test.sh)
• Verified visually on a live desktop: applied a scratch theme with an alacritty.toml lacking [colors.selection], confirmed the generated selection differed from foreground, and checked Alacritty/Neovim/gum/btop selection highlights were visible before reverting to the original theme