## What happened

When reconnecting to an already-saved WPA2-Enterprise (802.1x/PEAP) WiFi network through the top-bar network panel by re-entering credentials, the panel does not reuse the existing, correctly-configured NetworkManager connection profile. Instead it always creates a brand-new, minimal connection with the same name/SSID via a hardcoded script, and that ad-hoc profile can fail to authenticate (observed reason `no-secrets` in the NetworkManager journal within seconds of activation). The panel then surfaces this as a credentials/password error to the user, even though the pre-existing profile (created separately, e.g. by an institution's eduroam CAT installer) authenticates successfully with the exact same identity and password when activated directly via `nmcli connection up`.

## Root cause (found in shell source)

`/usr/share/omarchy/shell/plugins/panels/network/Model.js`:

- `enterpriseConnectScript` (line 319) always does `nmcli connection add type wifi con-name "$1" ssid "$1" ... wifi-sec.key-mgmt wpa-eap 802-1x.eap peap 802-1x.phase2-auth mschapv2 802-1x.identity "$2" ...` — hardcoded to PEAP/MSCHAPv2 with no CA cert, no anonymous identity, and no domain match, and it creates a **new** connection profile every time rather than checking for/updating an existing one with the same SSID. It also sets `802-1x.auth-timeout 8`, which appears too short for real-world eduroam-style RADIUS proxying (multi-hop federation auth commonly takes longer than 8s).
- `networkFailureReason()` (line 328) maps `WifiAuthTimeout` unconditionally to `"Wrong password"` for any credentialed network reconnect, per the comment: *"An auth timeout on such a network means the saved passphrase is wrong"* — this assumption doesn't hold for enterprise networks, where a timeout commonly means a slow RADIUS round trip, not a bad password.
- `shouldRepromptPassphrase()` (line 344) reopens the password prompt on `NoSecrets`/`WifiAuthTimeout` for any credentialed network, including ones already marked `known`, compounding the loop.

`/usr/share/omarchy/shell/plugins/panels/network/Panel.qml` (~line 764-775) wires the prompt submission to `enterpriseConnectScript`, confirming every manual-credentials submission takes this create-new-profile path.

## Steps to reproduce

1. Have a working WPA2-Enterprise (802.1x/PEAP+MSCHAPv2) WiFi connection profile already saved in NetworkManager (e.g. `nmcli connection show` lists it, and `nmcli connection up <name>` succeeds and gets a DHCP lease).
2. In the Omarchy top-bar network panel, select that same network and re-enter identity + password when prompted (as a user might do after being told/assuming the network "isn't connecting").
3. Observe: a new connection profile with the same name is created (`nmcli connection show` briefly lists a second entry, or `journalctl -u NetworkManager` shows a fresh `connection-add` for the same SSID), it fails quickly, gets deleted, and the panel reports a password/credentials failure — while the original, untouched profile still authenticates fine via `nmcli connection up <name>`.

## Expected behavior

- If a known/saved connection profile already exists for the selected SSID+security type, the panel should activate that profile directly rather than always creating a fresh minimal one.
- A `WifiAuthTimeout` on an enterprise network should not be unconditionally reported as "Wrong password" — a slower RADIUS round trip (common with federated eduroam-style auth) is a normal, non-credential-related outcome and 8 seconds is likely too aggressive a timeout for this case.

## System details

- Omarchy version: 4.0.3-1
- Kernel: Linux horizon 7.2.3-arch1-3 x86_64
- Network: NetworkManager 1.58.1-1, wlan (iwlwifi)

## Evidence

Journal excerpt showing the ad-hoc profile created by the panel (`connection-add`/`connection-update` by the quickshell process), failing with `no-secrets`, then being deleted, followed by the pre-existing profile succeeding moments later on its own:

```
audit: op="connection-add" uuid="7ad8a94d-..." name="eduroam" ... result="success"
audit: op="connection-update" uuid="7ad8a94d-..." name="eduroam" args="802-1x.password" ... result="success"
audit: op="connection-activate" uuid="7ad8a94d-..." name="eduroam" ... result="success"
device (wlp0s20f3): Activation: (wifi) disconnected during association, retrying connection
device (wlp0s20f3): state change: need-auth -> failed (reason 'no-secrets', managed-type: 'full')
device (wlp0s20f3): Activation: failed for connection 'eduroam'
audit: op="connection-delete" uuid="7ad8a94d-..." name="eduroam" ... result="success"
device (wlp0s20f3): Activation: successful, device activated.
```

(`omarchy debug` was not available as a subcommand on this installed version to attach a full diagnostic log.)