Pass _rev for optimistic concurrency on writes

[OwenTrokeBillard]

Currently write_note / edit_note have no staleness check. If two agents edit the same note concurrently, last-write-wins and one side's changes are silently lost.

CouchDB already tracks _rev on every document. Suggestion:

• Return the _rev (as an opaque revision token) from read_note / get_note_metadata.
• Accept an optional expected_revision on write_note / edit_note. If provided and stale, reject with something like { error: "stale_revision", current_revision: "..." } so the caller can re-read and retry.

Optional keeps current ergonomics; opt-in gives careful agents a safety net.

[es617]

Thanks, @OwenTrokeBillard, for the well-thought-out proposal; the opt-in expected_revision design is exactly right, and there's no breaking-change risk.

I'd accept a PR for this, but flagging the main wrinkle: _rev only exists in CouchDB mode. Local-filesystem mode has no native revision concept, so it'd either return undefined (concurrency check effectively disabled) or fake it via mtime/content-hash. I am fine starting with CouchDB-only and leaving local mode as a follow-up.

Happy to review if you or anyone else wants to take it on.

[OwenTrokeBillard]

This is something Claude flagged during setup. Not pressing enough for me to make a PR, just wanted to mention it somewhere. Thanks for the awesome project 🙏