feat(transaction): implement the remaining drafted actions

[wjones127]

Stacked on #8630. Implements the four actions the Transaction V2 draft still listed as unwritten — AddOverlays, RefreshRowVersionMetadata, UpdateCompactedSsTables, and AssertUniqueKeys — plus the lowering of the two legacy operations that map cleanly onto them. With this the implemented vocabulary covers the whole draft.

Three of the four are ordinary deltas. The fourth, AssertUniqueKeys, is the first thing in the vocabulary that is a precondition rather than a change: it carries the filter of key hashes a merge-insert is about to insert, so that two concurrent inserts can be shown not to collide. Nothing in the manifest records which keys exist — the key columns are an unenforced primary key — so the filter has to travel with the operation because it cannot be recovered from any post-image.

Example

Appending rows and asserting their keys are new, in one commit. If a concurrent commit inserted rows without saying which keys they carry, this one is rejected, because there is nothing to compare against:

CompositeOperation::new(vec![UserAction::new("insert new customers", vec![
    Action::AddFragment(AddFragment { local: 0, physical_rows: 500, .. }),
    Action::AddDataFile(AddDataFile { fragment: Ref::Local(0), file, .. }),
    Action::AssertUniqueKeys(AssertUniqueKeys {
        key_fields: vec![Ref::Committed(0)],
        filter: inserted_key_hashes,
    }),
])])

Conflict rules

Two of the new actions needed something the footprint could not previously express.

An overlay writes no coordinate at all. Overlays are appended, never replaced, and when two cover the same cell the newer committed_version wins — so two concurrent overlays must not collide with each other. What an overlay does need is for its fragment to still be there, which is a dependency rather than a write, and is now tracked as one.

A key assertion is not a coordinate either, because a row a concurrent writer inserts has no id anyone could name. The footprint gained a row-insertion marker (set by an AddFragment that is a data change, so a compaction rewrite does not count) and the assertions themselves. Two sets are compatible when both say which keys they insert, over the same columns, and the filters provably do not intersect; an unqualified insert, different key columns, or filters built with incomparable parameters all leave the assertion unverifiable, which counts as a conflict.

Breaking changes

One change to the (unstable, pre-vote) draft wire format: the Action oneof field update_compacted_sstables is renamed to update_compacted_ss_tables, so the generated variant name matches the UpdateCompactedSsTables message name — which is what the action vocabulary keys the wire encoding off. The tag is unchanged.

Per the plan for this stack, the format changes get folded into the first PR at the end so they are a single vote.

Behaviour differences from the legacy path

The legacy UpdateMemWalState arm of the manifest build never carries the read version's fragments into the manifest it produces, so committing it against a non-empty table empties it. The action path leaves the data alone, which is what the operation means. The parity test asserts both, so the difference is recorded rather than hidden; the legacy bug is untouched here.

A key assertion is compared symmetrically, so a plain append concurrent with a merge-insert conflicts in both directions. The legacy check only runs from the retrying transaction's side, so an append that lands after a merge-insert is currently allowed through and can introduce a duplicate key.

Not included

Operation::Update still has no translation. It is the last large one, and it lowers onto most of the vocabulary at once — tombstones, new fragments, compaction bookkeeping and a key assertion — so it belongs in its own change. Merge and Project remain untranslatable from the operation alone, for the reason the module documents: both hand over a whole new schema rather than a description of what changed.

[github-actions]

Important

This PR touches the Lance format specification.

Substantive changes to the format specification — the .proto definitions
and the spec docs under docs/src/format/ — require a PMC vote before merge.
Minor edits such as typo fixes, wording, or formatting are excluded; use your
judgment.

If this is a meaningful format change:

• Start a vote following the Lance community voting process.
  Format specification modifications need 3 binding +1 votes (excluding the
  proposer), held on GitHub Discussions, with a minimum voting period of 1 week.
• Once the vote passes, link the completed vote in this PR. It should not be
  merged until the vote is linked.

[wjones127]

Superseded by #8646, which also adds the vertical-form Update translation and moves the branch head into this repo for GitHub's native stacks. The protobuf changes described here now live in #7954.