feat: add authoritative incremental decision memory

[alpiua]

What this adds

This PR gives long-running coding agents a safer way to use project memory: they can tell whether a recalled item is still backed by its source, update only files that changed, replace an obsolete decision without erasing history, and send concurrent writes through one durable writer.

The problem

Semantic similarity alone cannot answer whether an old memory is still authoritative. Full project re-mines are expensive for small edits, and implicit "replacement" risks silently discarding verbatim history. At the same time, independent MCP clients can contend for the local write path.

Implementation, by reviewable commit

1. Memory freshness from authoritative sources — 6854769

Why: callers need to distinguish current evidence from memory whose backing source changed or disappeared.

How: adds optional authority_uri, authority_version, and memory_kind metadata; opt-in local-file verification reports current, stale, or unverified. Verification is cached within a search and duplicate ranked hits are removed.

Result: legacy memories remain compatible and unverified by default; agents can opt into freshness checks before relying on recalled context.

2. Incremental project updates from a changed set — 9d91aa3

Why: a producer that already knows which files changed should not have to trigger a full filesystem walk.

How: introduces a validated, project-relative {changed, deleted} manifest; preserves containment checks and tombstones; cleans up newly ignored files; and scopes re-indexing to the affected wing.

Result: small edits can update the correct memory slice without weakening source safety or reprocessing an entire project.

3. Explicit, reversible decision replacement — cf7546e

Why: replacing a decision must be deliberate and must not delete the verbatim rationale it supersedes.

How: requires an exact non-empty decision_key plus predecessor ID. The old drawer remains stored as superseded history; ordinary search hides it unless history is requested.

Result: agents retrieve the current decision by default while audits can follow the full decision trail. Semantic similarity never supersedes a record implicitly.

4. One durable writer for concurrent MCP clients — 0851bac

Why: process-lifetime peer locks make concurrent write behavior fragile and provide poor diagnostics when a job stalls.

How: routes mutating MCP calls through the daemon, with leased and heartbeated jobs, recovery of expired leases, coalescing of file events, bounded synchronous waits, and sanitized job-status endpoints.

Result: concurrent clients submit work safely through one write lane, while callers can inspect progress without receiving queued write payloads.

Compatibility and safety

• New metadata and MCP parameters are optional.
• Existing drawers are never assumed current; they report unverified until verification is requested.
• Authority adapters are local-file-only in this iteration; no external source is contacted.
• Changed-set paths cannot escape the project root.
• Supersession preserves verbatim history and requires explicit identifiers.
• The daemon serializes writes; reads remain direct.

Validation

• uv run ruff format --check . ✅
• uv run ruff check . ✅
• Full test suite is running locally; CI will rerun for this rewritten commit series.

Scope

This is a cohesive incremental-memory foundation, not a final schema or a hosted sync feature. Remote authority adapters and an idempotency key for daemon submissions remain future work.

[igorls]

Thanks for this contribution, and apologies for the slow turnaround.

develop has moved a fair way since this was opened and the branch no longer merges cleanly. If you're still interested in landing it, could you rebase onto current develop? Once it merges cleanly and CI is green I'll get it reviewed for the 3.8.0 cycle.

If you'd rather not pick it back up, no problem at all — just say so and I'll close it out, and thanks either way for taking the time to send it.

[alpiua]

Thanks for this contribution, and apologies for the slow turnaround.

develop has moved a fair way since this was opened and the branch no longer merges cleanly. If you're still interested in landing it, could you rebase onto current develop? Once it merges cleanly and CI is green I'll get it reviewed for the 3.8.0 cycle.

If you'd rather not pick it back up, no problem at all — just say so and I'll close it out, and thanks either way for taking the time to send it.

Hi @igorls
I rebased the branch to upstream/develop.