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.