fix(core): reject stale file reconciliation

[phernandez]

Why

A note write accepted through MCP or the browser can race with file indexing that
started from an older Tigris object. Before this change, the stale indexing pass
could reconcile its older Markdown back into note_content, effectively making
an accepted write disappear from the canonical database state and file history.

This is the Core half of the single-editor persistence work tracked in
https://github.com/basicmachines-co/basic-memory-cloud/issues/1589.

What Changed

• Capture the canonical note_content reconciliation state before indexing an
  existing Markdown file.
• Reconcile the indexed file only when the canonical state still matches that
  captured anchor.
• Keep legitimate external file changes: an unrelated file checksum may still
  advance canonical state when the prior file write was fully synchronized and
  its file/database versions and checksums agreed.
• Defer reconciliation explicitly when a concurrent accepted write changed the
  canonical state while indexing was in flight.
• Treat initial note_content absence as an anchor rather than disabling the
  optimistic check for newly indexed entities.
• Re-read and re-index the current file when a stale pass is detected so entity,
  observation, relation, and search projections cannot finish on old Markdown.
• Fail for normal job retry if a second concurrent write also makes the bounded
  immediate retry stale.
• Cover stale races, stable external changes, and dependency wiring with focused
  regression tests.

Implementation Details

NoteContentReconciliationAnchor records the pre-index canonical version,
checksums, and file-write status. FileIndexer captures that anchor before
parsing an existing Markdown file and passes it to the reconciler after the
entity update.

The reconciler treats the anchor as an optimistic concurrency boundary:

• If current canonical state differs from the anchor, the index pass is stale
  and cannot promote its file content.
• If current state still matches, equal checksums remain a no-op.
• A different file checksum can be promoted only from a fully synchronized
  baseline (file_write_status == "synced", equal file/database versions, and
  equal file/database checksums).

Reconciliation returns an explicit current or stale outcome. A stale
outcome makes the per-file indexer run one fresh pass from current storage,
repairing every derived projection. A second stale outcome raises rather than
reporting a false success, allowing the existing indexing job retry policy to
converge later.

This preserves first-writer CAS behavior without adding locks or a second
version authority.

Testing

• uv run pytest -q tests/indexing/test_note_content_reconciliation.py tests/indexing/test_note_content_reconciler.py tests/indexing/test_file_indexer.py tests/indexing/test_index_batch_runtime.py tests/indexing/test_note_content_batch_reconciliation.py
  • 44 passed
• just fast-check
  • Ruff and formatting passed
  • type checking passed
  • only pre-existing Python 3.14 asyncio deprecation diagnostics remain
• git diff --check

Risks / Follow-ups

• This PR changes only Core reconciliation. The Cloud follow-up will pin the
  merged Core SHA and publish the File History conflict-resolution UI already
  verified locally.
• The full development browser conflict matrix will be rerun after Cloud is
  pinned to this Core change.
• No production deployment is included.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c26b3415e1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".