task-49: record what wiuf-vpn-gate got wrong, and remove it from the phone

Found still installed 2026-08-01, in no repo and no repo's history. Three
defects, all traps the state-machine version can repeat:

- driven by the NM dispatcher and a 90s timer while calling nmcli up/down,
  which is itself an NM event - an actuator wired into its own sensor. 652
  recycles in 90 minutes is ~7/min, a loop, not a bad interval.
- on_home_wifi() matched ' inet 10.10.' - a /16 test that reads foreign
  10.10.30.x as home and drops the tunnel as redundant. The phone is on
  10.10.30.213 right now, and TASK-49's own measurements were taken there.
- managed CONN=wiuf while the phone carries both wiuf and wiufph, neither
  autoconnecting.

Files removed from the device; no dispatcher hook referenced them.

docs/tasks/49-bearer-selection-as-device-state.md

@@ -108,6 +108,49 @@ layer is the gap and this is the right thread. If MPSS itself has crashed or is
 Distinguishing those two is the whole next step — do not flip the config first,
 because a reboot destroys the evidence either way.
 
+## What `wiuf-vpn-gate` actually got wrong — read before designing the Action
+
+The script that produced the 652 recycles was found still installed on the
+phone 2026-08-01, in no repo and in no repo's history — it was written straight
+onto the device. Removed then; its two defects are the durable part, and both
+are traps the state-machine version can walk into just as easily.
+
+**1. It was driven by the NM dispatcher *and* a 90 s timer, and it changed the
+thing the dispatcher watches.** `nmcli connection up/down` is itself an
+NetworkManager event, so every correction re-entered the controller. 652
+recycles in 90 minutes is ~7/minute — far faster than the 90 s timer alone can
+explain, and the signature of a feedback loop rather than a bad interval. This
+is the same shape as the `hypridle` `lock_cmd` self-loop: an actuator wired
+back into its own sensor. In the §12 form the state machine is the only writer
+and `tick()` is the only clock, which forecloses it by construction — but only
+if bearer changes enter through `sensor_input` and never call back in.
+
+**2. Its home-LAN test is wrong on exactly the network this phone uses.**
+
+```sh
+on_home_wifi() { ip -4 addr show wlan0 | grep -q ' inet 10\.10\.'; }
+```
+
+That matches `10.10.` — so it treats **any** 10.10/16 address as home and takes
+the tunnel down as "redundant". The phone sat on `10.10.30.213` on foreign wifi
+while this was installed, and TASK-49's own 2026-07-31 measurements were taken
+at `10.10.30.213` on "Mabee 19". Home is `10.10.20.0/24`. A /16-wide prefix
+match cannot tell the home LAN from a foreign network that happens to share the
+first two octets, and this one does.
+
+**3. It managed the wrong profile.** `CONN=wiuf`, but the phone carries *two*
+WireGuard connections — `wiuf` and `wiufph` — and `wiufph` is the one with the
+`10.10.20.6` identity. Both are `autoconnect=no`, which is the real reason the
+tunnel does not come back after a reboot; the gate was the thing papering over
+that, badly. Deciding which profile is authoritative, and deleting the other,
+is a prerequisite to the grid — an Action cannot target "the VPN" while two
+profiles answer to that name.
+
+The lesson for the grid below: **"am I home" is not an address-prefix question.**
+It needs identity — the gateway's MAC, the SSID, or a reachability probe against
+something only the home LAN serves — and it is a piece of evidence with a
+confidence, not a boolean derived from a regex.
+
 ## The constraints any design must respect
 
 - **Not a daemon, not a dispatcher hook.** `VPN-WIUF.md` is explicit, and it was