Reference eight sleep rogue dhcp root cause

The prior memory (reference_eight_sleep_pod_connectivity.md) attributed Eight Sleep drops to 5GHz association on a merged SSID. That was a contributing hypothesis but the confirmed root cause was different.

The Gus The Bass TP-Link AP (MAC 50:3D:D1:15:5E:0A, now at 192.168.86.177) had its built-in DHCP server enabled. It was handing out leases that conflicted with the router, causing the Pod to get a bad address and drop cloud connectivity. This is also what caused the full network outage on 2026-06-12 (the AP on ether5 was identified as a rogue DHCP source on the MikroTik).

Fix applied 2026-06-12 (fully remotely after a physical pin reset): - AP admin password reset, strong password stored in ~/.forge-secrets/tplink.env - SSID rebuilt as Gus The Bus with same passphrase; Pod reconnected automatically - DHCP server disabled and verified off - Switch-level DHCP snooping enabled on the MikroTik as defense-in-depth (blocks any future rogue DHCP on wired/mesh) - AP manageable at 192.168.86.177 going forward

The 5GHz/dedicated-2.4GHz hypothesis in the prior memory should be treated as superseded. The Pod's connectivity issues were lease poisoning, not band steering.

[auto-memory session c8a7a69a-2433-4364-afbd-4101b3707290, confidence 0.85, mode direct]