**Omarchy version:** 4.0.1-1

## What happened

`omarchy theme set <name>` staged a user theme (`~/.config/omarchy/themes/<name>/`) whose `colors.toml` is a **relative symlink** (e.g. pointing into a dotfiles repo: `../../../../dev/dotfiles/omarchy/.config/omarchy/themes/<name>/colors.toml`). The result was silent, wide breakage:

- `~/.local/state/omarchy/current/theme/colors.toml` ended up a **dangling symlink** (relative path resolved from the wrong directory depth).
- Because that file couldn't be read, `omarchy-theme-set-templates` produced **no themed configs at all** — no `ghostty.conf`, no `shell.toml` bar colors/opacity, etc.
- The top bar lost its themed color/opacity, the terminal (ghostty) lost its color scheme, and any app reading the live state path directly (e.g. third-party apps that sync to `~/.local/state/omarchy/current/theme/colors.toml`) got nothing.
- No error or warning was printed anywhere in this pipeline — it looked like the theme had applied successfully.

## Root cause

In `omarchy-theme-set`, staging a non-repo user theme does:

```bash
cp -r "$USER_THEMES_PATH/$THEME_NAME/"* "$NEXT_THEME_PATH/" 2>/dev/null
```

`cp -r` copies a symlink **as a symlink** (doesn't dereference) verbatim. A *relative* symlink's target is only correct relative to its original directory. Once copied into `next-theme/` (and later swapped into `current/theme/`), the same relative path text resolves to a different, wrong location — dangling.

`stage_installed_theme`/`is_denied_installed_file` do handle symlinks specially for *installed* (git-cloned) themes, but that path isn't taken for a hand-authored user theme, so the plain `cp -r` above is what actually runs and hits this.

## Steps to reproduce

```bash
mkdir -p ~/realtheme
cat > ~/realtheme/colors.toml <<'TOML'
mode = "dark"
accent = "#89b4fa"
background = "#1e1e2e"
foreground = "#cdd6f4"
TOML

mkdir -p ~/.config/omarchy/themes/reprotheme
ln -s ../../../../realtheme/colors.toml ~/.config/omarchy/themes/reprotheme/colors.toml

omarchy theme set reprotheme

# Now check:
stat ~/.local/state/omarchy/current/theme/colors.toml   # -> dangling symlink
ls ~/.local/state/omarchy/current/theme/ghostty.conf     # -> missing
```

## Expected

Either:
1. `cp -rL` (dereference symlinks) when staging a user theme's files, so the *content* is copied rather than a potentially-invalid symlink, or
2. Validate after staging that `colors.toml` (and other staged files) actually resolve, and surface a clear error/warning instead of silently continuing with a broken theme.

## Workaround

Using an **absolute** symlink instead of a relative one for `colors.toml` avoids the bug, since `cp -r`'s verbatim copy then still resolves correctly regardless of destination depth. This is a viable workaround for anyone symlinking theme files in from a dotfiles repo, but the silent failure mode for anyone hitting this without knowing the cause is bad — no error anywhere in the pipeline.