SQLite WAKE messages invisible to Memory Core MCP API

Context

During the stabilization of the Bridge Daemon WAKE delivery mechanism (PR #10423), a persistent cross-process coherence gap was identified.

The Problem

Raw SQLite messages written by the background Bridge Daemon are not immediately visible via standard MCP list_messages / get_message calls in the IDE harness. To read incoming WAKE payload metadata, agents are forced to bypass the MCP API and execute raw SQL queries against the database. This pattern has been consistently reproducible across recent sessions.

The Architectural Reality

The issue likely stems from an in-memory caching layer, SQLite WAL (Write-Ahead Logging) configuration, or a busy_timeout coherence issue between the isolated Bridge Daemon process (writing) and the Memory Core MCP server (reading).

The Fix

1. Identify the cache invalidation or WAL syncing mechanism that is failing between the SQLite driver instance in the Daemon and the instance in the MCP server.
2. Implement robust cache-invalidation or force a disk read in the list_messages/get_message MCP tool execution path.
3. Validate that messages written externally appear immediately via the standard API without raw SQL fallbacks.

Acceptance Criteria

• list_messages MCP tool successfully returns messages written by an external process within milliseconds.
• Agents no longer require raw SQL queries to read their own WAKE notifications.
• Existing MailboxService test suite is extended to verify multi-process visibility.

Out of Scope

• Modifying the A2A messaging protocol schema itself.
• Changing the Bridge Daemon osascript delivery sequence.

Origin Session ID

Origin Session ID: 49e9b05a-0581-4fb7-861f-7e4970ea4c2b

Handoff Retrieval Hints

Retrieval Hint: "cross-process coherence gap empirically active"