### System details

Framework 13 (AMD Ryzen AI 7), Omarchy 4.0.1, kernel 7.1.9-arch1-2, `dockurr/windows`

### What's wrong?

`manual/28-windows-vm.md` documents hand-editing the compose as the way to customise the VM, and picks USB passthrough as the example:

> The compose file itself now lives at `/var/lib/omarchy/windows/docker-compose.yml` and is owned by root — that is deliberate, so a process running as you cannot rewrite it and have the privileged bring-up mount your whole disk into the container. **If you need to hand-edit it (for example to mount a USB device), edit it with `sudo`** and see all the options on [the Dockur Windows project].

So a customised compose is the expected state. Two paths then discard those edits, and neither is documented as doing so. I could not find any supported way to preserve them.

**1. `install` rewrites the compose — no upgrade involved.** The same manual page says resources are changed by *"re-running `omarchy-windows-vm install`, which rewrites the VM's configuration from your answers"*. Following both instructions in order — hand-edit to add a device, later re-run `install` to bump RAM — silently drops the hand-edits. This is reachable entirely within 4.0.1.

**2. The v3 → v4 migration deletes the legacy file.** `migrate_legacy_compose()` reads six values out of `~/.config/windows/docker-compose.yml` (`RAM_SIZE`, `CPU_CORES`, `DISK_SIZE`, `USERNAME`, `PASSWORD`, `TZ`), writes Omarchy's template from them, then:

```bash
  write_credentials "$username" "$password"
  rm -f "$LEGACY_COMPOSE_FILE"        # bin/omarchy-windows-vm:364
```

No backup is taken. On v3 that file lived under `$HOME` and hand-editing it was the only way to customise, so this is exactly the population the manual has been instructing since `Install > Windows` shipped in v2.

Everything outside those six values is dropped without mention. From one real compose, all of it standard Dockur usage:

- `devices:` — `/dev/kvm`, `/dev/net/tun`
- `device_cgroup_rules:` — required for USB hot-plug
- `cap_add: NET_ADMIN`
- `/dev/bus/usb:/dev/bus/usb:rshared` — keeps USB hot-plug working across hub re-enumeration, i.e. the manual's own example use case
- published ports beyond 3389 (5555, 5900, 8006)
- a user-defined network with a static `ipv4_address` that services inside the guest were pinned to
- `restart:` and `stop_grace_period:`

The user is left with a working VM whose USB passthrough, extra ports and static address have quietly gone, and nothing to diff against.

Related: #8619 covers the opposite failure of the same function — migration *rejecting* a valid legacy compose and stranding the VM — along with the discarded stderr in `status`/`stop`/`remove` and the misleading "not configured → run install". This issue is about what happens when migration *succeeds*.

### Steps to reproduce

1. On Omarchy < 4.0.1 with the Windows VM installed, hand-edit `~/.config/windows/docker-compose.yml` as the manual suggests — one extra published port is enough to demonstrate it.
2. Upgrade to 4.0.1.
3. Run `omarchy-windows-vm launch`.

The compose is replaced by a rendered template and the original is deleted. (Per #8619, `status` and `stop` reach the same code path.)

For path 1, no upgrade is needed: hand-edit `/var/lib/omarchy/windows/docker-compose.yml` with `sudo` as documented, then re-run `omarchy-windows-vm install` to change RAM.

### Suggested fix

Keep the original. One line before the removal:

```bash
  cp -a "$LEGACY_COMPOSE_FILE" "$LEGACY_COMPOSE_FILE.pre-quattro.bak"
  rm -f "$LEGACY_COMPOSE_FILE"
```

or `mv` it aside rather than deleting, so anyone who loses customisations has something to diff against. The same applies to `install` overwriting an existing compose — back it up first, or warn that hand-edits will need re-applying.

Longer term, the VM has no equivalent of the override mechanism the rest of Omarchy provides. `manual/31-dotfiles.md` establishes that `~/.config` is the user's and `/usr/share/omarchy` is Omarchy's; `manual/32-shell-plugins.md` gives plugins an explicit escape hatch (*"don't edit the files under `$OMARCHY_PATH` … clone it instead"*). The VM compose is in `/var/lib/omarchy`, which is neither, and the manual tells users to edit it in place. Either document that `install` rewrites it, or give it a supported override.

### Note

The surrounding code is careful about this class of problem — there is a comment explaining that `storage` and `shared` are reconstructed from `$HOME` rather than read back from the file, specifically so a rewritten compose cannot bind-mount `/` into the guest. And `manual/30-updates.md` does warn that `omarchy reinstall` overwrites user config. The silent `rm -f` here reads as an oversight rather than a decision.