feat(transaction): implement the Transaction V2 action vocabulary

[wjones127]

Stacked on #7954, which defines the Transaction V2 wire format. That PR defines the actions on the wire; this one implements them in Rust. It carries no format change of its own — every proto edit this stack needs now lands in #7954, so the format is a single vote.

Supersedes #8554, which had its head on a fork and so could not be part of a GitHub stack.

Today a transaction names one operation from a fixed list — Append, Delete, Merge, and so on — and each one is a post-image: it says what the dataset should look like afterwards. Two consequences follow. Work that spans several kinds of change needs several commits, so there is no way to add a fragment and then modify it atomically. And every new operation has to be taught how it conflicts with every existing one, which is an N-by-N table that grows quadratically.

This PR adds the delta-based alternative. A transaction can now carry a CompositeOperation: an ordered list of granular actions that commit together as one manifest change. Twelve actions are implemented — AddFragment, AddField, AddDataFile, AddBase, TombstoneFieldData, RemoveFragment, SetDeletionFile, AlterField, DropField, ConfigUpdate, ReserveFragmentIds, and ResetTable. Between them these cover the whole fragment, data-file, schema, and config surface; the drafted actions left for later are the index-segment, overlay, MemWAL, and assertion families.

Each action gets its own module holding its definition, how it is applied, which coordinates it writes, and its wire encoding, so one action can be reviewed — or added — without reading the other eleven.

Two things fall out of the delta model:

Steps can reference ids the same commit is about to create. An action that allocates a fragment, field, or base id names it with a local token; later actions in the same operation refer back to that token. Ids are minted when the actions are applied, against whichever manifest they land on, so replaying the same action set against a newer version simply produces different ids. Moving an action set to a newer version needs no rewriting at all.

Conflicts are decided by comparing write sets. Each action says which coordinates it writes — a field's data in a fragment, a fragment's deletion file, a field's definition, a base path's name, a config key. Two concurrent transactions can both commit when neither writes what the other writes. Adding an action means saying which coordinates it writes, not adding a row and a column to the conflict table. Footprints are computed at conflict time and never serialized, so a writer cannot pin down what a reader treats as a conflict.

Some writes cannot be enumerated, and those are tracked as such rather than approximated: removing a fragment writes everything inside it, replacing a config map writes keys it never names, and ResetTable writes the whole table, so it conflicts with any concurrent action set at all — including a pure append that writes no committed coordinate.

The two models interoperate. Append, Delete, UpdateBases, and DataReplacement can be translated into the actions they decompose into, which is both how an action set is checked against a concurrent named operation and the groundwork for squashing several operations into one commit. Each translation has a parity test that builds the manifest twice — once down the legacy path, once through the translation — and asserts the two agree.

Anything not yet expressible is rejected rather than approximated: an unimplemented action fails to parse, an untranslatable operation falls back to the conservative always-retry, and an action naming something that does not exist is an error.

Not included

Merge and Project are not translated. Both hand over a whole new schema instead of a description of what changed, so recovering the delta needs the read version's schema to diff against, which TryFrom<&Operation> does not have. The actions themselves are sufficient — Project is a set of DropFields and Merge a set of AddFields plus their data files — so this is a plumbing gap, not a vocabulary one.

Seven of the nineteen drafted actions are still unimplemented: AddOverlays, RefreshRowVersionMetadata, UpdateCompactedSsTables, AddIndexSegment, RemoveIndexSegment, AdjustIndexCoverage, and AssertUniqueKeys. Three of those need the index-segment model settled and three need the MemWAL and overlay subsystems; AssertUniqueKeys is not a delta at all but a precondition, so it needs a validation hook rather than an apply. Parsing any of them is an error rather than a skip, so an old reader cannot apply a partial transaction.

There are no Python or Java bindings. The Rust API is public but documented as a pre-vote draft, matching #7954's stability caveat, so it can change without a deprecation cycle.

Squashing several already-committed operations into one action set is left for later. The composite behavior it depends on is proven end-to-end here (rust/lance/tests/composite_transaction.rs), but rewiring one operation's committed references onto another's freshly minted ids is a separate problem.