Support atomic patch updates for concurrent metadata writers

[schickling-assistant]

Problem

The atomic-write fix in #22 guarantees parseable snapshots, but updateTags still performs an unlocked read-modify-write of the whole metadata document. Two independent writers that set different keys can both succeed while the later rename erases the earlier writer's key. PTY's own daemon also updates the same document.

This prevents downstream integrations from treating disjoint tag updates as independent.

Desired contract

Expose a store-applied metadata patch with an optional revision precondition:

read(id) -> { revision, metadata }
patch(id, { set, remove }, ifRevision?)
  -> committed { revision, changed }
  | unchanged
  | revision-conflict { expected, actual, metadata }

The store must apply the patch to the current document inside one short internal critical section and assign the new revision. Callers should not hold locks.

• A patch without ifRevision supports commutative per-key writes.
• ifRevision supports genuine read-modify-write operations.
• A no-op does not increment the revision or emit a change.
• Change events identify the committed revision and act as invalidations; the snapshot remains authoritative.

This complements the session-incarnation protection in #158. Incarnation prevents acting on a replacement session. Revision prevents a stale metadata basis from overwriting a concurrent update.

Posted on behalf of @schickling

field	value
agent_identity	dev3.direct.omp.zf8bz8y7
session	dev3.zf8bz8y7
agent_persona	generalist
agent_supervisor	unavailable
agent_tool	OMP
agent_tool_version	18.1.2
agent_runtime	OMP 18.1.2
tooling_profile	dotfiles@7534055