fix(status): poll pidfile registry as fallback for missed fs.watch events

[raphapizzi]

Summary

Fixes #61 — a Claude Code session waiting on an approval prompt renders with the green pulsing "Running Tool" dot and never fires the attention bell.

ClaudePidfileRegistry was 100% event-driven on a single fs.watch() watcher with no polling fallback. On macOS, fs.watch (FSEvents) is well known to coalesce or drop notifications for in-place rewrites of small files — exactly how Claude Code mutates its pidfile from status: "busy" to status: "waiting", waitingFor: "approve <Tool>". When that event is dropped, the in-memory snapshot stays stale forever (until the next subscriber-driven re-scan or app restart), and the entire status / attention pipeline downstream of it (mapPidfileStatus, attentionService.ingestSessionUpdate, StatusDot) silently acts on the wrong state.

What changed

• src/main/services/providers/claudePidfileRegistry.ts:

  • Add a 2-second polling rescan as a safety net alongside fs.watch. The watcher remains the low-latency primary path; polling guarantees eventual consistency.
  • scanAll now tracks whether anything actually changed and only calls notify() when changes are observed (or on the very first scan, to seed subscribers) — so steady-state polling does not spam downstream consumers.
  • refreshFile returns a boolean indicating whether the snapshot changed, so scanAll can aggregate without duplicating shallow-equal logic.
  • The poll setInterval is .unref()'d to keep CLI/test contexts from being held open.

• tests/unit/claude-pidfile-registry.test.ts:

  • New: polling fallback catches a busy → waiting transition when fs.watch is forcibly silenced — this is the direct regression guard for [Bug]: Status dot stuck on green "Running Tool" while session is actually waiting for approval (no notification) #61.
  • New: polling fallback stays quiet in steady state — guards against accidentally re-introducing per-poll notify storms.

Behavior

• Worst-case latency for a status transition (when fs.watch drops the event): ≤ 2s (was: never observed until next subscribe / app restart).
• Best-case latency (when fs.watch fires): unchanged.
• Steady-state CPU: one readdir + N small readFiles every 2s. Existing snapshots use shallowEqualSnapshot dedup; no work propagates downstream when nothing changed.

Test plan

• node node_modules/vitest/dist/cli.js run tests/unit/claude-pidfile-registry.test.ts — 10/10 pass (8 existing + 2 new)
• Full suite: node node_modules/vitest/dist/cli.js run — 330/330 pass
• Typecheck: tsc --noEmit -p tsconfig.node.json — clean
• Manual verification (will follow up with screen recording once dev build is running): trigger a Bash approval prompt and confirm the dot turns red + bell fires within ~2s without restarting the app.

🤖 Generated with Claude Code