refactor(table): split transaction.rs into a module tree

[wjones127]

Stacked on #8054, which is stacked on #8053. Review those first; this PR targets #8054's branch.

lance_table::transaction arrived as a single 6488-line file. This splits it into nine modules along the lines the code was already divided by, leaving transaction.rs as declarations, re-exports, and a map of where each concern lives:

module	lines	what it answers
builder	90	what a transaction is: an operation plus the version it was based on
operation	304	the vocabulary of changes an operation can describe
update_map	128	incremental edits to the manifest's string maps
validate	357	pre-commit checks against the manifest being replaced
manifest_build	1676	applying an operation to produce the next manifest
index_maintenance	1027	how that narrows or drops index metadata
row_version	1139	how it assigns row ids and per-row version metadata
conflicts	1027	whether two operations collide, for the commit retry path
proto	816	the persisted protobuf encoding of all of the above

Each of the nine commits extracts one module, so the "was any logic altered?" question is answerable a module at a time rather than across a 4000-line redistribution. Test counts hold at 57 throughout, and each commit compiles and passes on its own.

The 57 tests move with the code they cover. Six fixtures used by more than one module's tests live in a test_support module rather than being duplicated.

Nothing outside lance-table sees a change: the re-export list in transaction.rs is the same set of names the module exported before. Items used across submodules are pub(super) rather than pub(crate), since the submodules are private — clippy's pub(crate)-inside-a-private-module lint is what settles that.

One deliberate non-change: PartialEq for Operation and PartialEq for RewriteGroup each define their own local compare_vec. That duplication was there before and is left alone to keep every commit a pure move.

Not included

manifest_build stays the outlier at 1676 lines, of which build_manifest is about 890 and its tests about 700. The original plan was to break its 15-arm match into per-operation appliers in a manifest_build/ subdirectory, and I stopped short of it deliberately: unlike everything else here, that is not a move. Each arm mutates four or five pieces of shared state (final_fragments, final_indices, next_row_id, fragment_id), so extracting them means threading that state through &mut parameters, and a free function taking five &mut arguments is not obviously easier to read than the match arm it replaced.

Worth doing as its own PR if we want it, where the signatures can be discussed on their merits rather than riding along with a mechanical split.