fix(cli): refuse cascade sync while a server holds the memory root

[gloryfromca]

Summary

Every cascade command that writes the index — sync, fix --apply, rebuild — now acquires the OME jobstore lock (the same file and flags everos server uses) and holds it for its whole run. While a server or another exclusive CLI phase holds the root, the command exits 3 before opening anything; a server that starts mid-run fails at its own lock instead of becoming a second writer. status and fix (listing) are read-only and keep working next to a server.

Why: sync was deliberately exempted from the lock in #384 on the belief that draining from a second process is safe. The 10-hour Windows soak (PR #454) ran two cascade sync processes next to the server and ended with 1 158 / 1 219 / 1 241 duplicate global ids in episode / atomic_fact / foresight (4.3–4.6 % extra rows): same md_path, same content, updated_at ~14 s apart. Mechanism: the server's LanceDB connection keeps its own snapshot (read_consistency_seconds = None), so when another process inserts a row the server's merge_insert match phase still sees "no row" and inserts it again; two insert-only transactions do not conflict in Lance and no unique-key constraint exists. No consistency interval closes that window — a single writer does.

Behaviour change

• everos cascade sync and everos cascade fix --apply refuse (exit 3) while a server holds the memory root. Forcing a path to re-index while a server runs is no longer possible from the CLI; the watcher covers edits, and an API re-enqueue endpoint would be the way to bring that back.
• The refusal names the lock holder and the two cases where the server is not syncing (EVEROS_DISABLE_CASCADE=1, quiesced) so the operator knows to stop it first.
• The soak harness's "CLI storm" (two cascade sync processes next to the server, .work_context/lancedb_soak/harness) is retired by this change: every iteration exits 3. Its purpose — exercising cross-process commit races — is what this PR removes on purpose.

Verification

• Integration tests hold the real lock file the way a server does: sync and fix --apply exit 3 with get_engine patched to fail if reached (refusal precedes any DB open); fix and status still run; sync observes the lock held during its own drain (ome_lock_is_free() is False inside sync_once) and released after. Red without the held lock (3 failed), green with it.
• tests/integration/test_cascade_cli_integration.py + tests/unit/test_entrypoints/test_cli + tests/unit/test_memory/test_cascade: 295 passed. make lint green.
• Duplicate evidence: .work_context/lancedb_soak/results/windows_run1/summary.md (local), probe dup_probe.py.

Docs

docs/cascade_runbook.md: the sync section no longer says "safe to run in parallel with a live server"; the rebuild note no longer calls rebuild "the one command not safe next to a server"; the reference-file workaround says to re-save SKILL.md (or stop the server); docs/how-memory-works.md no longer suggests forcing the queue with sync for read-your-write.

Review round

An adversarial review of the first commit found: probe-and-release instead of a held lock, fix --apply ungated, the refusal claiming the server "already syncs" (false for EVEROS_DISABLE_CASCADE=1 / quiesced), a test that could not tell where the guard sat, and five doc passages still prescribing sync next to a server. All addressed in 2660d43.

🤖 Generated with Claude Code