[JingsongLi]

Purpose

Extend the existing Rust compaction API to Data Evolution append tables, which CompactBuilder currently rejects. Merge normal-column files while preserving stable row IDs, sequence metadata and logical deletions.

Follow-up to #1247; related to #286 as a Rust maintenance prerequisite. Python bindings remain separate.

Brief change log

• Select independent internal append, primary-key and Data Evolution planners through the shared public entry point. Each planner owns file eligibility, grouping and task generation; snapshot capture and serialized task types stay shared.
• Plan complete aligned row-ID groups and pack adjacent ranges using Java's Data Evolution binning rules. Support compaction.min.file-num=1 for single-file rewrites while ordinary append still requires at least two files.
• Stream merged normal-column values into one output per task, retaining input sequence bounds and per-column sequence metadata. Preserve dedicated Blob/Vector files, inline descriptors/views and global indexes.
• Move deletion vectors only from touched index files, rebasing on the latest snapshot on each commit attempt. Reject concurrent normal-column changes while allowing disjoint appends and preserving concurrent deletions.
• Preserve serialized task subsets and idempotent recovery, including CAS loss and lost publication responses.
• Reject rewrites that would discard historical inline values after a dedicated-storage option change, or exceed the current Rust deletion-vector writer's addressable local row positions.

Tests

• 64 compaction integration tests passed: 13 Data Evolution, 14 append and 37 primary-key cases.
• Core library regression: 4,642 passed, 6 ignored, rerun after the final review.
• Deterministic CAS coverage verifies both DELETE/COMPACT orderings, stale-message rejection with and without existing DVs, and successful fresh DELETE preparation.
• Recovery coverage includes a successful COMPACT followed by DELETE before its response is lost, coordinator restart after the captured snapshot expires, and nonadjacent subsets of three tasks sharing one DV index.
• Java reference tests: 160 cases passed across DataEvolutionCompactCoordinatorTest, DataEvolutionNormalCompactTaskTest, ConflictDetectionTest and DataEvolutionDeletionVectorTest.
• cargo fmt --all --check and git diff --check passed.
• Focused Clippy passed with -D warnings -A clippy::nonminimal_bool. Strict Clippy reports four existing nonminimal_bool diagnostics in unchanged files.

Coverage includes four data formats, nulls, historical snapshots, field renames/name reuse/type promotion, nested updates, dedicated files, index freshness, both DV storage layouts, independent subsets and concurrent commits. A Java/Rust output-artifact roundtrip was not run.

API and Format

Reuse new_compact_builder() and TableCommit::commit_compact; no new public API or storage-format version. Scope is normal files in unaware Data Evolution append tables with row tracking and no primary key.

DV migration runs in Rust snapshot preparation on every CAS attempt. Java prepares the migration separately against a fixed snapshot and rejects concurrent DV replacement; Rust rereads the latest DVs while revalidating the compacted data inputs. If COMPACT publishes first, a DELETE prepared against replaced anchors/indexes is rejected and must be prepared again.

Dedicated Blob/Vector compaction, large-file splitting and deletion materialization remain unsupported. With deletion vectors enabled, a compact output may contain at most 4,294,967,296 physical row slots until 64-bit DV writing is available.

Documentation

Update docs/src/compaction.md with Data Evolution planning, row/sequence preservation, deletion-vector handling, concurrency and supported limits.

[leaves12138]

LGTM