0.1.35

Two fixes found while re-verifying the 0.1.34 merge fix.

Automatic merging stopped working on vaults with more than ~500 saves

Conflict resolution looked up versions by scanning the change feed from the beginning, capped at 500 entries and ordered oldest-first. Every save is a change event, so once a vault's history outgrew a single page, the versions it needed were never in the window — and every concurrent edit forked a conflict copy instead of merging, silently and permanently.

This affected exactly the vaults that need merging most: the active ones. If you've been seeing conflict copies pile up where a clean merge should have happened, this was why.

Fixed by looking up the two versions directly instead of scanning history. Also removes a 500-row fetch on every conflict.

A second case where an edit could be silently dropped

0.1.34 fixed the merge dropping one side's change around repeated identical lines, but its guard checked whether the deleted block repeated elsewhere. A diff can re-express one edit as a completely different set of hunks wherever repeated lines allow it, so a block that looks unique can still be assembled from lines the alignment could have taken from anywhere — and one deletion still went missing. The check now works line by line.

Rare (about 1 in 350,000 merges) but the same failure mode as 0.1.34: the dropped edit re-diverges and the devices keep re-resolving the same conflict.

Verification

An invariant suite covering identity, symmetry, idempotence, convergence and per-line content counts, across 346k structured and ~360k random cases — no failures. Realistic concurrent note edits still merge cleanly 89.7% of the time, with the remainder falling back to safe conflict copies.

Requires the matching backend deploy, which is already live.