fix(daemon): WAKE/idle stability — end the consolidation CPU storm and serve recall on wake

[Marsu6996]

Summary

At WAKE the daemon never actually idled. The consolidation interrupt-check
treated an open MCP socket — and the liveness watchdog's own {"type":"status"}
probe — as "activity", so the sleep cycle never completed and the wake hook
re-fired every ~30 s. On top of that, on a graph-cache miss every background
subsystem (boot preload, sigma audit, foraging, the hippea cascade) recomputed
the full community graph concurrently under the GIL until the liveness
watchdog's socket probe timed out, the daemon SIGKILLed itself, and launchd
relaunched it — a self-sustaining CPU storm. This is the root cause the
maintainer deferred from #17 to this PR. The daemon now genuinely hibernates
when idle, computes the runtime graph once per wake, and reliably serves its
socket on wake; CPU at rest drops from a continuous 90–300 % to 0 %.

This supersedes the original "hibernate when idle" change (kept as the first
commit) and is rebased onto v1.1.4.

What changed (one logical change per commit)

• Hibernate when idle — the interrupt-check keys off last_activity_ts
  recency only, and the socket server refreshes last_activity_ts solely for
  dispatched JSON-RPC method calls (real recall/capture), never for control-plane
  status probes. This is the core "always-busy" defect.
• Single-flight build_runtime_graph — concurrent WAKE callers collapse into
  one compute (leader computes + saves the cache, followers reload it cheaply),
  with a bounded re-contend loop that degrades a leader failure / key-shift to
  sequential single-flight, never an N-way re-storm. Recall is independent of
  the community assignment, so a slightly-stale shared result is safe.
• Widen the cache staleness window 10 → 250 — a normal day of capture
  (+~150 records / +~1300 edges) crossed ~130 key buckets at WINDOW=10, missing
  the cache on essentially every WAKE. The 25 h / dirty>50 fuse in
  consult_overlay remains the real freshness backstop.
• Drop the boot-preload double-save that overwrote the good cache with a
  node_payload=None one, forcing a pandas re-read of every record on the next hit.
• Signal wake before kickstart — WakeHandler.signal_wake() (symmetric to
  consume_wake_signal) + a best-effort signal before the launchctl kickstart, so
  a hibernating daemon enters WAKE and serves recall instead of hibernate-exiting
  within a tick. Becomes essential once hibernation actually works.
• Exclude tombstoned records from the runtime graph — build_runtime_graph
  added every record/edge including soft-deleted / deduped ones, desyncing the
  node count from active_records_count() (the cache-validity anchor) so the cache
  was permanently invalid and every wake did a full rebuild on an oversized graph.
  On a real store this is 9733 → 3612 nodes. The cached community assignment is
  dropped only when the live set shrank (len(cached) > records_count, i.e.
  tombstoning) so dead nodes are recomputed away; ordinary growth keeps the cached
  assignment so a single insert is still absorbed by the staleness window without
  an O(n²) recompute (regression-guarded by test_runtime_graph_cache).
• A store-count failure must not read as empty — _store_is_empty() returned
  True on any exception; a transient HippoIntegrityError (sqlite left in an
  error state by a heavy reader) then parked the whole tick on a populated store.
  The unknown case now returns False so the tick proceeds.
• Reset last_tick_skipped_reason on a successful tick — a single early skip
  left a healthy, draining daemon permanently reporting skip=empty_store in
  .daemon-state.json. Cleared on any non-skipped tick.
• Keep the idle countdown awake during active drains and RPC — the countdown
  only read the Node wrapper heartbeat, so a stale heartbeat during a live
  deferred-capture drain forced SLEEP (an EXCLUSIVE store lock) into the in-flight
  drain. It now also folds capture.is_drain_in_progress() and recent RPC via a
  pure, unit-tested _idle_countdown_decision helper. A genuinely idle daemon
  still advances to DROWSY/SLEEP; explicit FORCE_SLEEP/user-sleep is unaffected.

Type of change

• Bug fix
• New feature
• Refactor (no behaviour change)
• Documentation
• Build / tooling

Affected areas

• Capture path
• Recall / retrieval
• Consolidation / sleep cycles
• Daemon lifecycle / FSM
• Storage / encryption at rest
• MCP wrapper (TypeScript)
• Bench harness
• CLI / doctor
• Other: ___

Testing

• pytest passes locally — full default gate
  (pytest -m "not perf and not slow and not live", 3538 tests), rebased on
  v1.1.4: 3514 passed, 33 skipped, 1 xfailed, 1 failed. The single failure is
  test_daemon_fdlimit_and_fsm.py::TestPlistRendersFdFloor::test_rendered_plist_contains_fd_floor,
  which is pre-existing — it fails identically on a clean v1.1.4 checkout
  (isolated, 0.13 s), so it is not introduced by this branch. (A set of
  test_doctor_* rows is environment-flaky on the dev machine — subprocess.run
  decoding a large system output as strict UTF-8 — and passes on a clean run.)
• ruff check src/ tests/ — no new findings vs the v1.1.3 baseline on the
  touched files (the repo ships no ruff config; pre-existing default-rule findings
  are untouched).
• New tests added for changed behaviour — single-flight collapse,
  socket activity tracking (probe vs RPC), tombstone exclusion, store-empty
  semantics, drain-aware idle countdown, and tick-flag observability.

Benchmarks

This PR changes daemon scheduling / CPU, not retrieval quality: recall is
independent of the community assignment, and no ranking or scoring path is
touched, so bench.* retrieval-quality numbers are unaffected by construction.

Live worst-case verification on a real ~4 k-record store (cold cache, all
subsystems forced at boot, default watchdog, status probe hammered for 90 s):

• Before: CPU a continuous 90–300 % (9–12 cores during the storm); watchdog
  socket probe times out; periodic KeepAlive=Crashed relaunch loop.
• After: probe latency 0.07–0.74 s throughout; 0 new forensic dumps, 0
  wedge-kills; CPU 1–3 cores during the single compute, then 0 % at rest.

Notes for reviewers

• Rebased onto v1.1.4 (upstream released v1.1.4 mid-review; our files are
  disjoint from its changes, so the rebase was conflict-free). This branch expands
  the original PR with the graph-tombstone, store-empty, tick-reason and
  drain-aware-idle fixes that the same WAKE/idle failure mode needed.
• Fixes Sleep daemon stuck in crisis_mode: cycle loops on a single step (never completes) while sleep-cycle --force works; served recall degrades to flat 1.000 / schema records #17 — this is the CPU-storm / "daemon treats itself as always-busy"
  root cause you flagged as the follow-up tracked here. A companion PR handles the
  consolidation-correctness half of Sleep daemon stuck in crisis_mode: cycle loops on a single step (never completes) while sleep-cycle --force works; served recall degrades to flat 1.000 / schema records #17 (crisis topology computed on a live,
  tombstone-filtered graph; recall score clamp; reflection embedding; crash-mid-
  SLEEP recovery) and is marked Relates to Sleep daemon stuck in crisis_mode: cycle loops on a single step (never completes) while sleep-cycle --force works; served recall degrades to flat 1.000 / schema records #17 so it does not auto-close the
  issue ahead of this one.
• Cooperates with the v1.1.3 crisis auto-expiry, does not duplicate it: the
  crisis_mode_since_ts timeout clears a coherent crisis after 72 h; this PR
  removes the false WAKE busy-loop that kept re-arming it.
• CACHE_VERSION is intentionally not bumped (the window change already
  invalidates old keys); a hygiene bump can follow.
• Follow-up (noted, not blocking): sigma.compute_topology_snapshot recomputes
  communities in-memory after build_runtime_graph and could reuse the assignment
  already returned.

[Marsu6996]

Converting to draft to hold the merge for now — not a problem with the change itself, just being cautious.

While investigating daemon stability on my setup I ran into a separate, not-yet-characterised behaviour: when the daemon is forced into WAKE, the graph-similarity computation (gemm/rayon in the native module) drives CPU very high (~9 cores). I stopped it before I could tell whether it eventually converges or is simply being cut short by the watchdog status probe (5s timeout, 3 strikes → self-SIGKILL), so I don't yet know if it's a real runaway or just heavy-but-bounded work killed too early.

Since this PR changes when the daemon hibernates vs. stays awake, I'd rather confirm it doesn't mask or interact with that WAKE-path behaviour before it lands. I'll re-mark it ready once I've measured it properly (let it run in WAKE with the watchdog relaxed and see if CPU settles). #19 is independent of this and stays ready.

[CodeAbra]

Thanks for digging into this, and sorry I went quiet. I ran into the same bug on my side and have been working through a fix since yesterday, which is why I was slow to reply. Your write-up lines up with what I was seeing.

Let me get my version landed first, then I'll go through your PR properly so your find gets credited. Really appreciate the careful report.

[Marsu6996]

Thanks — glad it lines up with what you were seeing, and good that you've got a fix in flight too.

No problem at all landing yours first. Please take anything useful from this PR, and don't worry about attribution on my account — I'm mainly just glad the bug's getting closed.

One thing in case it's useful for sanity-checking your version: the bit I'd been unsure about — whether the WAKE CPU is a real runaway or just heavy-but-bounded work the watchdog cuts short — is settled; it's bounded. The trigger is the graph cache missing on essentially every wake (staleness window of 10), so several subsystems recompute the full community detection concurrently and starve the event loop until the status probe times out.

Happy to rebase/trim this onto your fix or close it in favour of yours, whatever's least work for you. Thanks for the quick reply.

[CodeAbra]

Thanks — this is the WAKE/idle stability fix that ends the consolidation CPU storm and serves recall on wake. Reviewed the diff (socket-on-wake + interrupt-check tightening), security-clean, CI green. Merging with credit to you.