### Summary

`omarchy font set` truncates `~/.config/fontconfig/fonts.conf` and writes its own content over it. That file is the user's top-level fontconfig config, not Omarchy's — anything else kept in it (font substitutions, per-family aliases, rendering preferences, `prgname` scopes) is destroyed, with no merge, no backup and no warning.

The same happens via **Super+Space → Fonts**, since `Menu.qml` shells out to the same command.

The failure is hard to connect back to its cause: changing your *terminal font* silently deletes your *fontconfig customizations*, and nothing afterwards points at what happened.

Line references are against the packaged `omarchy-font-set` in 4.0.2-1.

### Why

`omarchy-font-set` L51–53:

```bash
fontconfig_file="$HOME/.config/fontconfig/fonts.conf"
mkdir -p "$(dirname "$fontconfig_file")"
cat >"$fontconfig_file" <<XML
```

`cat >` truncates. The script never reads the existing file, so it cannot preserve anything, and unlike `omarchy refresh` it leaves no timestamped `.bak`.

The comment above that block is right that fontconfig should be the source of truth — it is the choice of *file* that is the problem. `fonts.conf` belongs to the user; a program contributing one rule should use the drop-in directory.

### Repro

```bash
# add any rule of your own to your fontconfig
cat ~/.config/fontconfig/fonts.conf

# then set the font you are ALREADY using
omarchy font set "$(omarchy font current)"

cat ~/.config/fontconfig/fonts.conf   # your rule is gone
ls ~/.config/fontconfig/              # no backup
```

Verified on 4.0.2-1 with a `<match target="font">` rgba rule. Note the font does not have to change — re-running with the currently-active font is already destructive, so this can fire on what the user reasonably believes is a no-op.

### Suggested fix

Write to `~/.config/fontconfig/conf.d/50-omarchy-monospace.conf` instead of owning `fonts.conf`. The file can still be written wholesale — it just stops being a file that belongs to someone else, so no merge logic is needed.

Omarchy already uses this convention at the system level: the package ships `/usr/share/fontconfig/conf.avail/50-omarchy.conf`, linked into `/etc/fonts/conf.d/`. This would make the user-level write consistent with that.

The load order works out correctly, which matters because the current rule needs to override the package's `monospace` assignment:

```
/etc/fonts/conf.d/50-omarchy.conf   package drop-in (assigns monospace)
/etc/fonts/conf.d/50-user.conf      sorts after "50-omarchy", and includes:
    ~/.config/fontconfig/conf.d/*       <- proposed location
    ~/.config/fontconfig/fonts.conf     <- user's own file, still loads last
```

So a drop-in there is applied *after* the package rule (it can still override it, as today) and *before* the user's own `fonts.conf` (so a user rule still wins over Omarchy's — arguably the correct precedence, and an improvement on the current behaviour where Omarchy simply deletes it).

A migration could strip the `monospace` block from an existing `~/.config/fontconfig/fonts.conf` when that is all it contains, and leave the file alone otherwise.

If the drop-in move is unwanted, then at minimum back the file up the way `omarchy refresh` does rather than truncating in place.

### Environment

- omarchy 4.0.2-1
- fontconfig 2:2.18.3-2