fix(kb): character-level CRDT updates for node title/body/tags

[cuttlefisch]

ADR-092 D2 (design record in #624). Two coupled bugs — the second was hidden by the first.

1. Wholesale replace corrupted concurrent edits

KbNodeDoc::set_body/set_title did remove_range(0, len) + insert(0, new) on a YText. Two peers editing the same field from a shared base converge and lose neither edit — but each tombstones the base once and re-inserts its own full copy at origin 0, so the text neither peer touched survives once per peer:

Line one.        <- shared base
Line two.
From A.
Line one.        <- shared base, DUPLICATED
Line two.
From B.

A 500-line node edited concurrently became 1000 lines of doubled text. Titles concatenated outright: "Design Notes (draft)Design Notes v2". set_tags had the same bug in YArray form: ["rust","kb","from-a","rust","kb","from-b"].

Why no test caught it. Both existing "convergence" tests only ever have peers edit different fields — three_client_concurrent_edits_converge says so in its own comment. The one same-field test asserted a.body() == b.body(), and that oracle is worthless here: a CRDT gives convergence for free, so it passes on garbage. The oracle that matters is that the untouched base appears exactly once.

The fix extracts the diff core from TextSync::reconcile_to into reconcile_text_ref, so the buffer path and the KB-node path share one implementation (principle #8) rather than one correct and one not. reconcile_to delegates with no behavior change — its existing tests, including utf16_reconcile_with_emoji, pass unmodified as the regression guard. Also corrects its doc comment, which claimed OffsetKind::Bytes; new_doc configures OffsetKind::Utf16.

2. op_set::materialize depended on op order — and the order was wrong

Fixing #1 broke three daemon tests. Root cause was not the new diff:

materialize seeded from opened.ops[0], but ops[0] is not the structure op. open_new_ops ranks by the update's state-vector total, and Update::state_vector() is non-empty only for a self-contained full-state op — every incremental delta reports an empty state vector, hence rank 0. Measured: root ranks 6, both child deltas rank 0. Ascending sort put the root last, so materialize always seeded from a delta, which carries no type for the other ops to attach to. Confirmed identical on main.

It worked there only by accident: the old bulk insert was one item yrs could integrate whenever the root arrived. Character-level updates emit many items and don't reconstruct that way.

Worse, op order is not causal and can't be made so — with every delta at rank 0 the sort falls through to op_id, a ciphertext hash, effectively random per author. Two deltas that do depend on each other can arrive reversed, leaving the later pending forever and silently yielding stale content (the v1 title where the author wrote v2).

Fixes:

• open_new_ops sorts self-contained ops before deltas, then rank, then op_id — still a total order, so peers replay identically.
• materialize combines all ops into one update via Update::merge_updates and applies it once, making the result a function of the op set, not delivery order. Re-applying in a loop is not a substitute — it panics inside yrs (block_store.rs:318).
• No unwrap on this path: an op-set is attacker-supplied ciphertext, so a forged or truncated op must degrade to an empty node, not panic the client.

Tests

All of the following failed before their respective fix:

• concurrent_same_field_edits_do_not_duplicate_the_untouched_base — selective oracle: base appears exactly once
• three_peers_editing_one_body_converge_identically_under_every_apply_order — ≥3 peers, all six orders, order-independence and base-once
• concurrent_title_edits_..., concurrent_tag_edits_do_not_duplicate_shared_tags
• reconciled_body_handles_utf16_surrogate_and_cjk_boundaries — emoji/CJK across a surrogate pair
• setting_a_field_to_its_current_value_produces_no_ops — an unchanged save grew the doc 111→125 bytes, churning tombstones into a replicated, compacted document
• open_new_ops_returns_a_self_contained_op_before_any_delta — pins the ordering invariant over 50 fresh keys (the tiebreak is a ciphertext hash; one iteration can pass by luck). Verified to fail against the old sort. Asserts its precondition so it isn't a tautology.
• an_op_set_missing_its_root_materializes_empty_without_panicking — a relay withholding the structure op yields empty, never partial content
• a_forged_op_that_decrypts_to_garbage_is_skipped_not_fatal

A storage-order permutation test was written and discarded as vacuous — merge re-encodes the op-set so all 24 permutations re-sort identically, and it passed against the broken code. It was testing merge, not ordering. Replaced with the direct ordering assertion above.

Also drops the // set_body replaces, so last-write-wins comment, which described the defect as the design.

Verification

• mae-sync 309 passed (×5 runs — these tests are hash-order-variable by construction)
• mae-core 3099 passed
• daemon workspace clean ×3 runs (separate lock, ADR-014)
• make pre-commit green

🤖 Generated with Claude Code