fix(pulse/imessage): block startIMessage until stop, ending supervisor restart loop

[janrenz]

Problem

Pulse/modules/imessage.ts:startIMessage() sets up the SQLite poll setInterval and then returns immediately. The supervisor in pulse.ts:supervise() treats the resolved promise as a clean exit:

// pulse.ts:200-205
await fn()
if (!shuttingDown()) {
  log("info", \`${name} exited cleanly, restarting in 10s\`)
  await Bun.sleep(10_000)
}

Every 10 seconds it re-invokes startIMessage(), where the running guard catches the duplicate call and emits a warn. pulse-stdout.log ends up with this pattern forever after the module successfully starts:

{"msg":"iMessage module already running, ignoring start request"}
{"msg":"imessage exited cleanly, restarting in 10s"}

The poll itself works correctly throughout — message ingestion isn't affected — but every 10s there's needless work plus log noise that drowns out real events.

Why this pattern is unique to imessage

modules/telegram.ts:345 already documents the same shape and how it avoided the bug:

// Start polling — await keeps startTelegram() alive until bot.stop() is called.
// Without await, the supervisor thinks the function exited and restarts it,
// causing a grammY 409 conflict (two polling loops on the same bot token).
await bot.start({ ... })

iMessage uses a bare setInterval instead of an awaited polling primitive, so the same protection was missing.

Fix (+15 lines, one file)

• Module-scope: let stopResolve: (() => void) | null = null
• End of startIMessage: after setInterval(...) and the polling every Xms log, await new Promise<void>(resolve => { stopResolve = resolve })
• End of stopIMessage: after running = false, release the captured resolver

With this, the supervisor sees startIMessage as long-running. The 10s restart cycle goes away.

Repro

1. Healthy macOS install with Full Disk Access granted to the launchd-supervised bun.
2. PULSE.toml [imessage] enabled with at least one allowed_handles entry.
3. tail -f ~/.claude/PAI/Pulse/logs/pulse-stdout.log | grep imessage shows the alternating start/exited lines every 10s.

After fix: a single iMessage module started → polling every 3000ms then silence (until a real inbound message or shutdown).

Notes

• No behavior change for inbound messages, replies, cursor persistence, or shutdown.
• stopIMessage() already idempotent on running=false; the new resolver release follows the same guard.
• A similar but separate pattern exists for the telegram module path where the module returns early on missing bot token — that produces the same 10s log spam. Out of scope for this PR; happy to follow up.

Found while wiring up iMessage on a fresh v5.0.0 install. Local fix verified: 0 already running warnings over 25s observation window after Pulse restart, vs. 3 in the same window before the fix.