## What happens

`omarchy dns <provider>` aborts with exit 2 as soon as its loop reaches a NetworkManager **port profile** (a bridge or bond member). Every connection processed before the abort is updated; every connection after it keeps its previous DNS. Nothing surfaces the failure when the command is triggered from the menu, so the switch silently applies to only part of the system.

```
$ omarchy dns DHCP
Error: invalid or not allowed setting 'ipv4': port connections cannot have IP configuration.
$ echo $?
2
```

## Steps to reproduce

No special hardware needed — two throwaway profiles are enough (the loop iterates over *profiles*, not devices, so the interface need not exist):

```bash
nmcli connection add type bridge con-name br-test ifname br-test
nmcli connection add type ethernet con-name br-test-port ifname eth-nonexistent controller br-test

omarchy dns DHCP     # -> Error: ... port connections cannot have IP configuration ; exit 2

nmcli connection delete br-test br-test-port
```

Anyone running a bridged setup hits this permanently: libvirt bridges, Docker/`br0` setups, USB-NIC bridges.

## Expected

Port profiles are skipped, the remaining connections are updated, and the command reports what it did.

## Root cause

`bin/omarchy-dns` filters candidates on connection **type** only:

```bash
networkmanager_dns_connection() {
  case "$1" in
    802-11-wireless|802-3-ethernet) return 0 ;;
    *) return 1 ;;
  esac
}
```

A bridge port is `802-3-ethernet`, so it passes the filter — but NetworkManager rejects any IP setting on it:

```
$ nmcli -t -f connection.type,connection.controller,connection.port-type connection show br0-port-XXXX
connection.type:802-3-ethernet
connection.controller:br0
connection.port-type:bridge

$ nmcli connection modify br0-port-XXXX ipv4.ignore-auto-dns no ipv4.dns "" ipv6.ignore-auto-dns no ipv6.dns ""
Error: invalid or not allowed setting 'ipv4': port connections cannot have IP configuration.
$ echo $?
2
```

With `set -euo pipefail` (line 7), that single failure kills the whole run inside `set_connection_dns()` / `clear_connection_dns()`.

## Why it goes unnoticed

`current_dns_provider()` reads only `/etc/NetworkManager/conf.d/20-omarchy-dns.conf` and `DNS=` in `/etc/systemd/resolved.conf` — never the per-connection settings. After a partial run it reports `DHCP` while most connections still pin `1.1.1.1` via `ipv4.dns` + `ipv4.ignore-auto-dns=yes`. On my machine the indicator said `DHCP` for weeks while three of four saved networks forced Cloudflare.

That has a real consequence: a captive portal redirects by hijacking the network's own DNS. With connections pinned to `1.1.1.1`, the portal's resolver is never queried, the login page never loads, and the Wi-Fi just looks dead — which is exactly the experience described in #9610. `resolvectl dns` is the reliable check:

```
before:  Link 2 (wlp0s20f3): 1.1.1.1 1.0.0.1      <- pinned, portal cannot redirect
after :  Link 2 (wlp0s20f3): 10.x.x.x             <- DHCP-provided, portal works
```

## Suggested fix

1. In `networkmanager_dns_connection()`, also skip profiles where `connection.controller` / `connection.port-type` (or the legacy `connection.master` / `connection.slave-type`) is set.
2. Do not let one `nmcli connection modify` failure abort the loop — report the skipped profile and continue.
3. Make `current_dns_provider()` take the per-connection settings into account, so a partial state is visible rather than reported as `DHCP`. (Related to #10245, which reports a different inaccuracy in the same function.)

## System

- Omarchy 4.0.3-1 (`bin/omarchy-dns` on the default branch is byte-identical to the installed copy, so this is current)
- NetworkManager 1.58.1-1, systemd 261.2-1, kernel 7.2.3-arch1-3

Related: #9610 (captive portal detection), #10245 (`omarchy dns` misreporting the provider).