Problem

When the gateway restarts (via openclaw gateway restart, config change, SIGUSR1, or LaunchAgent restart), inbound messages that haven't been fully processed are silently lost. This includes:

1. Followup queue items (FollowupQueueState.items) — these are in-memory only (resolveGlobalSingleton) and are discarded on process exit.
2. Messages arriving during the drain window — once markGatewayDraining() is called, new enqueueCommandInLane() calls reject with GatewayDrainingError, and channel plugins don't persist these rejected messages for replay.
3. Messages arriving while the gateway is down — channel-dependent; Slack Socket Mode may redeliver some, but there's no guarantee across all providers.

The existing restart sentinel system (restart-sentinel.json) only persists a single notification about the restart itself (status, reason, delivery context), not the pending inbound message queue.

Expected Behavior

Before shutting down for restart, the gateway should:

1. Persist any pending followup queue items (FOLLOWUP_QUEUES) to disk (e.g. state/pending-messages.json)
2. After restart, on startup, read and replay persisted pending messages through normal dispatch

This ensures that user messages sent during a restart window are not silently dropped.

Current Behavior

• chatRunState.clear() is called in server-close.ts, wiping in-memory state
• clearFollowupQueue() / queue GC removes pending items
• GatewayDrainingError rejects new enqueues but the rejected message is not persisted
• User experiences: message sent → no response → must manually repeat after restart

Reproduction

1. Send a message in any channel (Slack, Telegram, etc.)
2. Immediately trigger openclaw gateway restart before the reply is delivered
3. Observe the message gets no response after restart

Proposed Approach

Phase 1: Persist followup queues across restart

• In the close handler (before chatRunState.clear()), serialize FOLLOWUP_QUEUES entries to state/pending-messages.json
• On startup (in server-restart-sentinel.ts or adjacent), read the file and re-enqueue items via enqueueFollowupRun()
• Delete the file after successful replay

Phase 2: Handle drain-window arrivals

• When GatewayDrainingError is thrown, persist the rejected inbound context (channel, sender, message text, thread info) to the same pending file
• Replay these on next startup

Phase 3: Channel-level message acknowledgment

• For channels that support it (Slack Socket Mode, etc.), defer message acknowledgment until the message is either processed or persisted, so the platform can redeliver on restart

Impact

This particularly affects agent-initiated restarts (config changes, updates) where the agent triggers a restart while actively in a conversation — the user's most recent message(s) in the thread disappear silently.

References

• src/process/command-queue.ts — GatewayDrainingError, markGatewayDraining(), resetAllLanes()
• src/auto-reply/reply/queue/state.ts — FOLLOWUP_QUEUES (in-memory only)
• src/auto-reply/reply/queue/enqueue.ts — enqueueFollowupRun()
• src/gateway/server-close.ts — createGatewayCloseHandler()
• src/cli/gateway-cli/run-loop.ts — drain + restart flow
• src/infra/restart-sentinel.ts — existing restart notification persistence
• src/gateway/server-restart-sentinel.ts — post-restart notification delivery