Fall back to color8 for a derived theme selection color

[DeanWahle]

Symptom

A theme installed with omarchy theme install that ships only an alacritty.toml with no [colors.selection] block ends up with selection equal to foreground in its generated colors.toml. Every highlight that keys off that value renders as invisible text-on-text: Neovim's Visual and LspReferenceText, the selected item in gum confirm/gum choose prompts, and btop's selected process row.

Root cause

bin/omarchy-theme-colors-from-alacritty defaulted an absent selection background to the foreground:

selection_background=${selection_background:-$foreground}

Because the theme now has a colors.toml, omarchy-theme-color's own fallback chain for an unset selection never gets a chance to run. The key is already set, just set to the one value it should never take.

Fix

Use the same chain omarchy-theme-color applies at bin/omarchy-theme-color:229 for an unset selection, so the generator and the reader agree:

selection_background=${selection_background:-${color8:-${color0:-$background}}}

color8 is [colors.bright].black, or [colors.normal].black when the theme ships no bright palette. The normal colors are validated earlier in the script, so color8 is always set by the time this runs; the rest of the chain mirrors the canonical one rather than stopping short of it.

A theme that does declare [colors.selection] is unaffected.

Verified

Locally on bash 5.3, running the script directly against synthetic theme directories:

• Reproduced the bug on the unmodified script: a theme with no [colors.selection] generated selection = "#c0caf5", identical to its foreground.
• After the change, the same theme generates selection = "#414868", its color8.
• A theme that declares [colors.selection].background still gets exactly that value.
• A theme with no [colors.bright] gets its [colors.normal].black, confirming the chain follows color8 rather than reaching the foreground.
• Added test/shell.d/theme-colors-from-alacritty-test.sh covering those three cases. It fails on the unfixed script with expected: #414868 / actual: #c0caf5 and passes with the fix, so it is a real regression test rather than a restatement of current behavior.
• bash -n on both changed files, and test/shell.d/bin-style-test.sh passes.
• theme-install-guards-test.sh, user-theme-test.sh and vscode-theme-test.sh pass.

Not verified

I do not have an Omarchy system to test on, so this was not exercised through a real omarchy theme install or omarchy theme set, and I did not confirm the downstream rendering in Neovim, gum or btop; that part rests on the issue reporter's account and on the generated colors.toml now carrying the intended value.

test/shell.d/theme-staging-test.sh fails on my macOS checkout, but it fails identically on unmodified quattro, so it is an environment limitation rather than a regression from this change. I also could not complete a full test/shell run locally: unrelated Linux-dependent files hang partway through on macOS.