## What happened

When a theme installed via `omarchy theme install <url>` ships no `colors.toml` and its `alacritty.toml` has no `[colors.selection]` block, `omarchy-theme-colors-from-alacritty` falls back to using the foreground color as the selection background:

https://github.com/basecamp/omarchy/blob/master/bin/omarchy-theme-colors-from-alacritty

```bash
background="${COLORS[colors.primary.background]}"
foreground="${COLORS[colors.primary.foreground]}"
selection_background="${COLORS[colors.selection.background]}"
...
selection_background=${selection_background:-$foreground}
...
selection = "$selection_background"
```

That `selection = foreground` value then propagates through `colors.toml` into every downstream template that keys off `{{ selection }}` / `{{ selection_background }}` (`gum_env.lua.tpl`, `neovim.lua.tpl` via aether.nvim, `btop.theme.tpl`), since the theme now *has* a `colors.toml`, so `omarchy-theme-color`'s own fallback chain (`selection` -> `selection_background` -> `color8` -> `color0` -> `background`) never gets a chance to kick in for this key — it's already set, just set wrong.

Concretely, on affected themes:
- Neovim: `Visual` selection and `LspReferenceText`/`LspReferenceRead` (the "cursor sitting in a word" highlight) render as invisible text-on-text.
- Interactive `gum confirm`/`gum choose` prompts (e.g. `omarchy plugin add ... --enable`) render the currently-selected yes/no or list item as invisible.
- btop's selected process row (`theme[selected_bg]`) becomes invisible against `main_fg`.

## Steps to reproduce

1. Install any theme via `omarchy theme install <repo>` whose `alacritty.toml` has no `[colors.selection]` section and ships no `colors.toml` (e.g. a stripped/minimal alacritty-only theme).
2. `omarchy theme set <theme>`
3. Inspect the generated `colors.toml`: `selection` equals `foreground`.
4. Open Neovim, do `viw` on a word, or let an LSP attach and put the cursor on a symbol -> selection/highlight is unreadable.
5. Run any `gum confirm`/`gum choose`-based Omarchy command (e.g. `omarchy plugin add <url> --enable`) -> the highlighted yes/no option is unreadable.

## Expected

`selection`/`selection_background` should never default to the same value as `foreground`. A sensible default already exists in the codebase's own fallback chain used elsewhere (`color8`, else `color0`, else `background`) — the alacritty-derivation script should use that same chain instead of `$foreground` when `[colors.selection]` is absent.

## Fix applied locally

Per-theme workaround: hand-write a `colors.toml` in `~/.config/omarchy/themes/<name>/` with `selection` set to that theme's own `color8`, which pre-empts the buggy generator (it skips generation when `colors.toml` already exists). Confirmed this fixes both the Neovim and gum symptoms after `omarchy theme set`. This doesn't fix the generator itself for future/other themes though.

## System details

- Omarchy version: 4.0.1-1
- `omarchy debug --no-sudo --print` available on request

## Suggested fix

In `bin/omarchy-theme-colors-from-alacritty`, change:

```bash
selection_background=${selection_background:-$foreground}
```

to fall back through the same muted/color8 chain `omarchy-theme-color` already uses elsewhere, e.g.:

```bash
selection_background=${selection_background:-${COLORS[colors.bright.black]:-$color8}}
```

(with an ultimate fallback to `$background` if even that's unset), so a themed selection background is never identical to the foreground text color.