feat: support identity-safe reordered fragment rewrites

[LuQQiu]

Summary

• Write caller-reordered streams into uncommitted fragments while preserving stable row IDs and per-row created/updated version metadata.
• Preserve address-style row addresses in output order so existing indices can be remapped after a physical permutation.
• Allow callers to reserve final output fragment IDs before committing a rewrite, then commit those IDs without a second reservation.
• Add explicit fragment groups as hard compaction-planning boundaries.

Motivation

Some dataset maintenance operations physically permute existing rows instead of preserving input order. They still need to preserve logical row identity, keep existing indices correct, know final output fragment IDs when preparing associated work, and prevent later compaction from crossing caller-defined placement boundaries.

This PR adds generic write, remap, reservation, and planning primitives for those workflows. It does not define an ordering or partitioning policy.

Scope

This PR does not add fields to the transaction protobuf, change the Lance format, or combine a rewrite with a dataset-configuration update. Composite operations belong to Transaction V2.

Validation

• cargo fmt --all
• cargo check --quiet -p lance -p lance-table
• cargo check --quiet in python/
• cargo check --quiet in java/lance-jni/
• cargo test --quiet -p lance reordered --lib: 8 passed
• cargo test --quiet -p lance explicit_fragment_groups_are_hard_compaction_boundaries --lib: 1 passed

[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.