Reference eight sleep cloud dependent cooling

Root-caused 2026-07-03: the Eight Sleep Pod 4 hub can stay fully alive on the LAN (strong wifi, valid IP, pings fine, bridges through the AP) while losing only its session with Eight Sleep's cloud. When that happens, cooling stops completely, Eight Sleep built cooling as cloud-dependent, there is no local fallback mode. HA's Eight Sleep integration also masks this: it keeps serving cached/stale sensor values (e.g. water temp updating hourly) even while the cloud says online: false, so HA history is not trustworthy for diagnosing outages, only Eight Sleep's own cloud API (online/lastHeard fields) is ground truth.

Why: A prior fix (cutting HA polling from every 30-60s to hourly, to stop ~7,200/day cloud hits from causing session contention) reduces the frequency of drops but doesn't prevent them or restore cooling once a drop happens, this is a distinct problem from [[reference_eight_sleep_pod_connectivity]] (which focused on wifi/DHCP causes, since disproven by Justin, the AP/wifi band was never the issue).

How to apply: When Justin reports a bad night's sleep or cold/warm bed with the Pod, check Eight Sleep's cloud online/lastHeard directly (not HA sensor state) to find the actual drop time. The proposed mitigation in progress: put the hub on a smart plug (15A, Pod 4 draws up to ~120W) with an HA watchdog polling cloud status every ~10min overnight, auto-power-cycling the plug on drop, then re-sending the cooling command. Justin needs to supply the smart plug; nothing else can proceed until then.

[auto-memory session 1ba3ed50-8f5a-4aba-b791-6f29da59f8a9, confidence 0.85, mode direct]