## What happened

On a stock Omarchy install with Docker, the "Custom" DNS provider (`omarchy dns Custom`) cannot actually reach a custom DNS server if that server's IP is `172.17.0.1` — which is a very plausible address for a home router to use, since it's the classic default Docker bridge gateway that many admins deliberately avoid... except Omarchy's own Docker defaults still hardcode that same address in three different places, unaware that the user's router might be sitting on it too.

In my case, my OPNsense router's LAN (and its DNSCrypt-proxy instance) is `172.17.0.1`. Running `omarchy dns Custom` and entering `172.17.0.1` silently failed to reach the router — `systemd-resolved` was instead falling back to the FallbackDNS (Quad9), and after a NetworkManager restart it failed outright with `Configured DNS server loops back to us`.

## Root cause

Omarchy's Docker defaults set the bridge gateway to a non-default subnet, but forgot to update two related config files (and a firewall rule) to match:

- `/etc/docker/daemon.json` (shipped by `omarchy-settings`) sets `"bip": "172.30.0.1/16"` — moving Docker's bridge off the classic `172.17.0.0/16` default — but its `"dns"` field is still hardcoded to the old default gateway: `"dns": ["172.17.0.1"]`.
- `/etc/systemd/resolved.conf.d/20-docker-dns.conf` (also shipped by `omarchy-settings`) sets `DNSStubListenerExtra=172.17.0.1` — the same stale address — so `systemd-resolved` binds a local DNS stub listener there to let containers resolve via the host.
- `/usr/share/omarchy/install/config/firewall.sh` installs matching `ufw` rules for this trick, also hardcoded to `172.17.0.1`:
  ```
  ufw allow in proto udp from 172.16.0.0/12 to 172.17.0.1 port 53 comment 'allow-docker-dns'
  ufw allow in proto udp from 192.168.0.0/16 to 172.17.0.1 port 53 comment 'allow-docker-dns'
  ```

Because `172.17.0.1` is the classic default Docker bridge gateway, it's a real-world-plausible LAN address too (in my case, my OPNsense router's LAN uses that exact subnet). When a user's actual router lives at `172.17.0.1`, that address now refers to *both* the real router *and* a `systemd-resolved` socket this host itself is listening on. Any DNS query aimed at the real router (e.g. via `omarchy dns Custom` → `172.17.0.1`) is instead captured locally by the host's own Docker-DNS stub listener, which either silently falls back to `FallbackDNS` or fails with "Configured DNS server loops back to us" — the real router's DNSCrypt/Unbound instance is never reached at all.

## Steps to reproduce

1. Have (or simulate) a router/DNS server whose IP is `172.17.0.1` — this is common enough to hit by accident, since it's Docker's own historical default gateway.
2. Install Omarchy with Docker (`omarchy install docker` or equivalent), which ships the three files above.
3. Run `omarchy dns Custom` and enter `172.17.0.1`.
4. Observe: `resolvectl status` never shows `172.17.0.1` as `Current DNS Server` — it silently uses `FallbackDNS` instead, or fails with `Configured DNS server loops back to us` (confirm with `resolvectl status` / `journalctl -u systemd-resolved`).

## Expected behavior

`omarchy dns Custom` with a valid, reachable DNS server IP should actually use that server, regardless of whether it happens to match Docker's default bridge gateway.

## Suggested fix

Derive the Docker-DNS stub listener address consistently from wherever `bip` is set (`172.30.0.1` in the current defaults), instead of hardcoding the old `172.17.0.1` default in three separate places:
- `/etc/docker/daemon.json`'s `"dns"` field
- `/etc/systemd/resolved.conf.d/20-docker-dns.conf`'s `DNSStubListenerExtra`
- the `ufw allow ... to 172.17.0.1 port 53` rules in `install/config/firewall.sh`

so they can never coincide with a real external network the user might configure via `omarchy dns Custom`.

## System info

- Omarchy: 4.0.3-1
- Kernel: 7.2.3-arch1-3
- Docker: 29.7.2
- `docker0`/default bridge: `172.30.0.1/16` (per `/etc/docker/daemon.json`)