Windows cached stores can block watcher publication

[lzl51230]

Problem

A background watcher reindex can run while the MCP server owns a cached SQLite read handle. The Windows SQLite VFS opens without FILE_SHARE_DELETE, while the graph writer publishes with MoveFileExW. The cached handle can therefore block the atomic replacement before the post-success stale-store notification runs.

This was found while implementing SVN auto-watch in #1113.

Evidence

• src/main.c: the watcher invokes the server-less supervised index before calling cbm_mcp_server_mark_store_stale.
• vendored/sqlite3/sqlite3.c: Windows share mode is read/write only.
• internal/cbm/sqlite_writer.c: the writer documents that incompatible open handles make replacement fail.

Suggested direction

Add an MCP-owned Windows pre-index quiescence handshake: finish any in-flight query, close the cached handle on its owning thread, block new graph requests until publication completes, then reopen on the next query. Keep POSIX generation handoff unchanged. Add a native Windows same-session test with a pre-warmed query store.

[DeusData]

Thanks for tracing the Windows publication failure through the cached read handle and MoveFileExW. This is a high-priority 0.9.1-rc stability bug because any background reindex can hit it, not only SVN. The proposed quiescence handshake is one possible design; the RED acceptance case should first prove same-session publication with a pre-warmed MCP store on native Windows while concurrent requests remain bounded and the old graph stays queryable on failure.