fix(invalidate/store): wire reconcileWrite into the live write path; BEGIN IMMEDIATE for read-modify-write

[JoshKappler]

Two concurrency holes in durable writes, both invisible to a green suite because each needs a second writer.

1. The no-silent-LWW guard never runs in production. STATUS §14 advertises "resolveConflicts + reconcileWrite optimistic concurrency (never silent LWW)", but reconcileWrite has no live call sites. On the real path (learn() -> classifyRelation), two parallel sessions' default remembers (workspace scope, user-asserted, equal precedence) classify as refines: the newer fact supersedes the older. A SUPERSEDES edge gets recorded, but no dispute is surfaced, so the loser dies quietly. The parallel-conflict eval stayed green because section 5 called reconcileWrite directly instead of going through learn().

Fix: at equal precedence between two user-asserted facts, the invalidator routes the refines decision through reconcileWrite. A writer that passes base_seen_fact_id (the fact it read before writing, from recall or why) supersedes cleanly. A writer that never saw the value it contradicts gets conflicts: both facts disputed, CONFLICTS_WITH edge, conflict note at injection, resolve_conflict settles it. Deterministic parser facts are exempt; their evidence is commit-anchored, so re-extraction still refreshes values without disputes.

base_seen_fact_id is threaded through Runtime.learn, rememberFact, and the MCP remember tool (optional input; still exactly 8 tools, I8 untouched). Interactive writers do the read-then-write themselves: the CLI remember command and the TUI prompt resolve the current fact at write time (new Runtime.currentFactIdFor) and pass it as their base, so a human deliberately updating a value supersedes exactly as before, and the core-memory-lifecycle eval's remember -> supersede check stays green. The asymmetry is deliberate: the human at the terminal sees the value they're replacing; a parallel agent session usually doesn't.

Behavior change to flag: an MCP remember that contradicts an existing equal-precedence value without base_seen_fact_id now returns status: "disputed" instead of silently winning. That's the SPEC §14 contract; agents get the base id from recall/why. The eval's section 5 now drives real learn() races and asserts the new outcome mix.

2. Overlapping promotion sweeps lose promotions permanently. tx() is BEGIN deferred, and the sweep reads candidates then writes inside one deferred transaction. Two processes on one WAL DB (a SessionEnd hook racing the MCP daemon's checkpoint or promote) both snapshot; the first commits; the second's first write throws SQLITE_BUSY_SNAPSHOT, which busy_timeout does not retry. The hook swallows the error (I9), and since the sweep is scoped to the now-ended session, no later sweep revisits those candidates. The promotions are gone, not delayed.

Fix: txImmediate in store/db.ts (both drivers expose .immediate on wrapped transactions), used by the probation sweep, reviewFactForWorkspace, and the invalidator's apply path. The writer lock is taken at BEGIN, so concurrent read-modify-write serializes through busy_timeout and each sweep runs on a fresh snapshot.

New tests: test/invalidate/concurrent-writes.test.ts (dispute without base seen, clean supersede with it, the interactive currentFactIdFor flow, precedence and parser-refresh guards) and test/store/tx-immediate.test.ts (two connections on one file DB: reproduces SQLITE_BUSY_SNAPSHOT under deferred, proves the immediate tx commits while the concurrent writer fails fast and retryable, plus wiring checks that the sweep and apply run immediate). Counters 292 -> 301.

Verification (Windows 11, Node 22):

npx tsc --noEmit                  # clean
npx biome check src test          # clean
npx vitest run                    # 289/301; the 12 failures are the pre-existing
                                  # win32 set the Windows PR fixes
npx tsx src/cli.ts eval conflict  # 62/62, silentOverwrites 0, real learn() races

eval all can't run on Windows without the Windows PR's .cmd fix, so the full battery ran on a local merge of the two branches (counters 306): vitest 306/306, eval all 19/19 including the core-memory-lifecycle remember -> supersede check, bench within budget.

Note: all three PRs bump the README/STATUS test counters off the same base (292), so whichever merges second and third will conflict there. I'll rebase the counters as each one lands.

[chai1any]

The core direction looks right, but I found one functional blocker in the MCP conflict-resolution surface: the new disputed facts are not reachable by resolve_conflict, so the surfaced conflict cannot actually be settled through the advertised tool.

The issue is in src/mcp/tools.ts: conflictCandidates only pulls facts through userScopedActive / activeAsOf, and those repo APIs filter status = active. This PR changes equal-precedence contradictory remembers to mark both facts disputed, so the conflict disappears from the resolver immediately after creation.

I confirmed it on the branch with a small Runtime/MCP scenario: two default rememberFact writes for repo/package_manager become disputed, then the MCP resolve_conflict handler returns { winners: [], conflicts: [] }. Please include disputed facts in this candidate set and add a regression test for that exact MCP path.

Targeted checks still passed on the branch: npx tsc --noEmit, npx biome check src test, and npx vitest run test/invalidate/concurrent-writes.test.ts test/store/tx-immediate.test.ts test/eval/parallel-conflict.test.ts test/runtime/forget.test.ts (17 tests passed).

[JoshKappler]

Fixed in 7790c88. conflictCandidates now folds in disputed facts through a new FactsRepo.disputed(scope) view, with the same scope layering as the active queries (user-global, current workspace, current session). Your repro is pinned as a regression test on the exact MCP handler path in test/mcp/resolve-conflict.test.ts: two default remembers for repo/package_manager -> both disputed -> resolve_conflict returns one winner + one surfaced conflict instead of {winners: [], conflicts: []}. A second case covers session-scoped disputes (reachable with session_id, invisible without).

Also merged main into the branch and rebased the doc counters. Two things came out of that:

1. The counter guard in eval cli-docs-demo compares docs against the live vitest list count, and main is currently red on it (297 vs 303 linux / 304 windows). The 303-vs-304 split is the win32-only home-paths test: it.runIf excludes it at collection time, so the live count differs by platform and no single counter could match both. I switched it to a runtime ctx.skip (e495638) — still Windows-only at run time, but collected everywhere. This branch sits at 315 on both platforms and the guard passes.

2. The other red on main CI is the SPEC §24 latency budget: p95 came in at 159ms (ubuntu runner) and 379ms (windows runner) against the 150ms budget — shared-runner hardware, not a regression; local runs pass with big margin. I left it alone since the budget is a spec decision. Happy to send a small follow-up if you want a CI-aware budget (multiplier via env) or to keep the strict 150ms as a local/bench-only gate.

Verified on Windows 11: tsc clean, biome clean src+test, vitest 315/315, eval all 19/19.