Keep warm primary bootstrap read-only and bounded

[chubes4]

Problem

Primary-mode warm bootstrap still runs the synchronization owner inline from WP_Markdown_DB::db_connect(). PR #250 bounds contenders, but the owner can spend longer than Studio and WP-CLI startup deadlines reconciling a large canonical store before WordPress receives control.

On the intelligence-chubes4 site, deploying merged PRs #249 and #250 reduced is_blog_installed() from roughly 6-10 minutes to 87 seconds, but startup still never reached the HTTP listener before the CLI deadline. The daemon log stopped after WordPress already installed; skipping installer; port 8881 remained unbound.

Root cause

Warm boot_connection() selects sync_incremental, and run_primary_loader_action() invokes sync_incremental_if_available() inline. The process that acquires the gate therefore remains responsible for the complete canonical scan and SQLite mutation before bootstrap can continue.

Required contract

• Warm primary bootstrap opens and serves the last complete index without inline reconciliation.
• Read-only WordPress and WP-CLI boots complete within a fixed deadline regardless of canonical store size.
• Reconciliation runs at an explicit deferred maintenance boundary with single-owner, process-safe authority.
• Cold reconstruction remains fail-closed and publishes only complete indexes.
• Deterministic coverage proves the synchronization owner cannot delay warm bootstrap, not only that contenders return quickly.

AI assistance

OpenAI GPT-5.6 Sol via OpenCode correlated the deployed MDI fixes with Studio daemon timing, traced the remaining delay to the inline warm loader action, and drafted this report. Chris Huber directed the investigation and remains responsible.

[chubes4]

Reopening with a current regression against the same acceptance contract. A large primary store redirected bootstrap to a 1.8 GiB rebuildable index; WP-CLI and Studio failed with Error establishing a database connection, and an integrity check did not complete within 120 seconds. The stock SQLite database passed integrity immediately, and temporarily selecting mirror mode restored WordPress and unrelated workspace-control commands immediately. Warm primary bootstrap is therefore not bounded/read-only in the operator-visible path, or it cannot distinguish an unavailable index from a database connection failure. Acceptance should include a hard startup deadline, typed index health/recovery evidence, and proof that a slow rebuildable index cannot make unrelated WP-CLI control-plane commands unavailable.\n\nAI assistance: OpenAI GPT-5.6-sol via OpenCode reproduced the bootstrap failure, compared primary and stock SQLite behavior, correlated the result with the closed tracker contract, and drafted this update. Chris Huber directed and owns the report.