### System details

Omarchy 4.0.1-1; Tailscale 1.102.3; existing Tailscale installation upgraded through migration `1785101000.sh`

### What's wrong?

After updating Omarchy, `omarchy-tailscale-receive.service` was enabled and started but could not receive files. It wrote the following error to the user journal every ten seconds:

```text
getting WaitingFiles: Access denied: file access denied
Use 'sudo tailscale file get --wait --conflict=rename ~/Downloads/.omarchy-taildrop'.
To not require root, use 'sudo tailscale set --operator=$USER' once.
```

#### Cause

Migration `1785101000.sh` enables the receiver for an existing Tailscale installation without ensuring that the desktop user is configured as the local Tailscale operator. By contrast, the current Tailscale installer runs `sudo tailscale set --operator="$USER"` before enabling the receiver.

The receiver treats every `tailscale file get` failure as transient, sleeps for ten seconds, and retries indefinitely. The systemd unit also has `Restart=always`, so a permanent authorization failure currently has no quiet terminal state.

#### Reproduction

1. Have Tailscale installed and connected without a local operator configured.
2. Update an existing Omarchy installation so migration `1785101000.sh` runs.
3. Observe that the migration enables and starts `omarchy-tailscale-receive.service`.
4. Inspect `journalctl --user -u omarchy-tailscale-receive.service` and observe the repeating access-denied messages.

#### Expected

The upgrade should not leave a permanently unauthorized receiver enabled and repeatedly logging the same error. Possible behaviors include requesting operator authorization before enabling it, leaving it disabled until authorization is granted, or stopping on a permanent permission denial with one actionable notification.

Because migrations run per user while Tailscale's `--operator` setting names one Unix user, I did not want to assume which privilege behavior Omarchy intends. I am happy to open a PR once that behavior is clear.

#### Relevant source

- The current Tailscale installer configures the operator before enabling the receiver: https://github.com/basecamp/omarchy/blob/quattro/bin/omarchy-install-service-tailscale
- The migration enables the receiver but does not configure or check the operator: https://github.com/basecamp/omarchy/blob/quattro/migrations/1785101000.sh
- The receiver retries every failure indefinitely: https://github.com/basecamp/omarchy/blob/quattro/bin/omarchy-tailscale-receive
- The user unit restarts the receiver whenever it exits: https://github.com/basecamp/omarchy/blob/quattro/default/systemd/user/omarchy-tailscale-receive.service

#### Workaround

Users who do not need automatic Taildrop reception can stop the repeated failures without disabling Tailscale:

```bash
systemctl --user disable --now omarchy-tailscale-receive.service
```

Filed by GPT-5 via Codex.