Merge commits record their merged value; legacy merges keep their values

[williamstein]

A patch with several parents (a merge commit) is a diff from the merged value
of its parents, so computing its value reran merge3: changing merge3 changed
the values of patches already in a history, and their hashes stopped
matching. Now:

• Session records the merged value of a merge commit's parents, as its author
  computed it: mergePatch, a diff from the exact value of mergeParent (the
  parent with the smallest diff). PatchGraph computes the value of such a
  patch from that parent alone, without merging, like a git merge commit
  records its tree. A later merge3 change only changes how new concurrent
  edits merge. patch keeps its meaning, so clients that do not know the new
  fields, and the apply-all fallback, read it as before.
• A merge commit without them and without a hash was written by a version
  that applied every patch in time order (patchflow 0.8, what CoCalc runs in
  production) or with that fallback's value. Its value is now computed the
  same way, from the patches its parents descend from (legacyValueOfSet),
  instead of with merge3, so existing histories keep the values their authors
  saw. It starts from the newest snapshot that contains every older patch it
  needs; a snapshot made after a concurrent patch does not.
• Undo of a merge commit reverts from the same recorded value.

Tests (merge-commit.test.ts): merge commits record their value; a different
merge3 gives the same values and matching hashes (and without the record
does not); readers without the fields agree; random 3-writer histories keep
every value under either merge3; 20 random histories written with apply-all
keep every value under merge3 and a different merge; a snapshot taken after
a concurrent patch is not a starting point; undo of a merge commit.

[williamstein]

Replay on real histories (the patch databases of a cocalc.ai project, written by patchflow 0.8 clients, no hashes): every patch value, or for histories over 2,000 patches every merge commit, the patch after it and every 25th patch, compared with the value 0.8 computes (apply-all), which is what its author saw.

	text files (113 files, 907 patches, 1 merge)	chats + notebooks (14 files, 4,342 checked, 496 merges)
patchflow 0.10.0	0 differ	306 differ (agent chats 186 and 41, lite2.ipynb 10, lite2.chat 69)
this PR	0 differ	32 differ, all in lite2.chat

All 32 are patches whose 0.8 value starts from a snapshot taken after concurrent edits (29 of that file's 115 snapshots), which drops those edits; for each, this PR's value equals applying the full history in time order. So 0.10.0 would change the values of existing production histories at deploy; this PR keeps them, apart from not repeating that snapshot loss.

[williamstein]

Addressed the review in 1e62282:

• P1 (unmarked ≠ apply-all): agreed, a missing hash doesn't identify the writer (0.9.x wrote exact-merge commits without one). The application now declares it: unmarkedMerges: "merge3" | "apply-all" on PatchGraphOptions/SessionOptions. The default "merge3" reads unmarked merges as 0.9/0.10 did. CoCalc, whose pre-hash history is patchflow 0.8, passes "apply-all". New test: the reviewer's v0.9.3 history (generated with the actual v0.9.3 Session) reads as helloA\nhelloB\ntail\n by default.
• P2 (quadratic legacy replay): legacyValueOfSet keeps checkpoints keyed by a hash of the replayed patch times from the same start, and continues from the longest match. New test: 150 fork/fork/merge rounds read merge by merge, every value equal to the author's. Patch applications: < 1,804 with checkpoints, 34,125 with them disabled.
• Contract question: intentional. A patch is held back until all its parents arrive, even when its merged value is recorded (causal delivery). New test documents it.

Replay of the real 0.8 histories with "apply-all": unchanged, 0 differing values except the 32 non-cut-snapshot cases in lite2.chat. 156 tests pass; lint and build are clean.

[williamstein]

Follow-up (e80ff64): per the maintainer, patchflow 0.9.x was never used in production (only test servers), so a merge commit without a hash or recorded merged value was written by 0.8. Dropped the unmarkedMerges option and its 0.9.3 fixture tests; such merges are read as 0.8 wrote them, as before. Kept the replay checkpoints (P2) and the causal-delivery test. 154 tests pass.

[williamstein]

Re-review P2 (checkpoint retained size) fixed in bcd25e0: the checkpoint LRU is now bounded by size like the exact caches (exactCacheMaxSize, docSize), and the newest checkpoint is kept apart so merge-by-merge reads still continue when one version doesn't fit. Regression test: a 200,000-character document with a 150,000 cache keeps ≤ 150,000 characters of checkpoints and applies < 4 patches per patch. It fails with the count-only cache (200,006 kept) and without the newest-checkpoint fallback (1,425 applications). 155 tests pass; lint and build are clean.