macOS: agents stop responding while the display is asleep (webview suspension)

Environment: Buzz desktop v0.5.3 (aarch64), macOS on Apple Silicon (Mac mini M4 Pro), self-hosted relay over Tailscale.
▎
▎ Summary: When the display goes to sleep, agents running in the desktop app stop responding to channel messages/mentions. Messages sent from the mobile app get no agent reply until the Mac's display is woken, at which point queued replies arrive all at once.
▎
▎ What we ruled out:
▎ - System sleep: pmset shows sleep 0; power logs confirm the machine never entered system sleep during the test window.
▎ - Networking: a background daemon on the same machine (Tailscale-connected) keeps working fine while the display is off.
▎ - App Nap: defaults write [xyz.block.buzz.app](https://xyz.block.buzz.app/) NSAppSleepDisabled -bool YES + app restart did not fix it — so this looks like WKWebView/occlusion timer suspension rather than App Nap.
▎
▎ Repro:
▎ 1. Desktop app running with an active agent in a channel; display sleep enabled (e.g. 10 min).
▎ 2. Let the display sleep.
▎ 3. Mention the agent from another client (mobile).
▎ 4. No reply until the display is woken; reply then arrives immediately.
▎
▎ Workaround: sudo pmset -a displaysleep 0 and powering the monitor off physically — with macOS believing the display is on, agents respond normally (verified).
▎
▎ Suggestion: for the 24/7 self-host use case, agent event routing/scheduling probably shouldn't live where macOS can suspend it with the window occluded — either take a power/webview assertion while agents are enabled, or move scheduling to the native side.