Summary

Currently, when the gateway is down (crash, restart, mac sleep, machine off), inbound iMessage messages that arrive during that window are not delivered to the agent once the gateway comes back up. The imsg watch subscription resumes from current state and ignores anything that landed in chat.db while it was offline.

This is the inverse of #62761 (which is about unbounded replay on restart). A bounded, cursor-persisted catchup would address both.

Why it matters

• BlueBubbles solves the equivalent gap via webhook replay + history fetch (see BlueBubbles: replay missed webhook messages after gateway restart (cursor + fetchBlueBubblesHistory + processMessage) #66721 for context, now closed).
• For users moving from BlueBubbles to the bundled iMessage plugin (PR feat(imessage): private-API support via imsg JSON-RPC [AI-assisted] #78317 / docs/channels/imessage-from-bluebubbles), losing webhook-replay-style catchup is a regression in availability semantics.
• For long-running setups on a Mac that sleeps, every wake currently risks silently swallowed messages.

Proposed capability (sketch — happy to iterate)

• Persist last-seen cursor. On every successfully-processed inbound ROWID, persist { accountId, lastSeenRowid, lastSeenTimestamp } to ~/.openclaw/state/imessage/inbound-cursor.json (file mode 0600, dir 0700 to match the other state files in this directory).
• On startup, replay bounded. After the bridge is up, query chat.db for messages with ROWID > lastSeenRowid AND date > lastSeenTimestamp - <bounded window, e.g. 24h>, dispatch each through the same inbound pipeline, then resume imsg watch.
• Bounded by recency, not just rowid. A 24h ceiling avoids the iMessage channel replays old messages after update restart — no cursor persistence #62761 unbounded-replay failure mode if the cursor file is corrupted, deleted, or carried across machines.
• Echo dedupe must still apply. Outbound messages we sent via imsg should not be re-ingested; the existing sent-echoes.jsonl window (currently 2 min) would need to extend to cover the catchup window, or we'd need a separate is_from_me filter at the cursor query.
• Per-account scoping. Multi-account configs need per-account cursors.

Out of scope for this issue

• Surfacing missed messages with a synthesized 'gateway was offline N minutes' marker (could be a follow-up).
• Catchup for plugins other than iMessage (BlueBubbles already handles this; Telegram has long-polling cursor; etc.).

Tracking

Filed off the back of PR #78317 review. Not blocking that PR — the bundled iMessage plugin is functional without catchup; this is a feature gap to close after.