feat: capture field findings into bundled skills (harness resources)

pineapple-control gains the uplink-pins-phy0 constraint, the five-part
pineapd crash stack, and the standalone PineAPE engine recipe; wifi-deauth
gains the field-verified passive-capture finding (clients that refuse the
evil twin still produce crackable 4-ways of the real AP, [B,1,2,3,4]).
Evil WPA playbook hint mentions the passive fallback. Skills are served to
agents via MCP resources.

payload/user/remote_access/pager-webui/skills/wifi-deauth.md

@@ -59,6 +59,21 @@ Monitors are effectively pinned to the channel their phy's AP interface holds (2
 
 The `handshake`/`hostap_handshake` tables and `/root/loot/handshakes` populate only for the Pineapple's OWN evil-twin AP (see §6). For the real AP, use a raw monitor capture:
 
+**Field-verified 2026-08-19 — the passive capture is GOLD (better than the twin):**
+pineapd's `handshake` table captures a full 4-way for ANY nearby AP the
+monitor can hear, even when the client refuses the evil twin entirely. In a
+live engagement, a target client (Nintendo Switch 2) got `auth status=1`
+rejections from the karma twin and never associated — but when it
+reconnected to the REAL AP, pineapd logged:
+`[HANDSHAKE] handshake AP <real-bssid> CLIENT <mac> crackable [B,1,2,3,4]`
+and wrote both `.pcap` + `.22000` files to `/root/loot/handshakes/` on its
+own. The monitor must be on the real AP's channel (on this lab unit the
+2.4 GHz monitor is pinned to the uplink's channel — see pineapple-control).
+The exported hashcat line verified against the target SSID:
+`WPA*02*<mic>*<apbssid>*<clientmac>*<ssid-hex>` — direct `hashcat -m 22000` input.
+Clients that DO associate to the twin also produce `hostap_handshake` rows
+(roaming client verified), so both paths produce loot.
+
 ```sh
 # single session: background tcpdump, run deauth rounds, listen, kill.
 tcpdump -i wlan1mon -s 3000 -w /root/loot/pcap/mon_$(date +%s).cap & TDPID=$!