fix(spec): rewrite field-scoped options on column rename

[u70b3]

Purpose

Linked issue: close #383

RenameColumn previously rewrote only fields.<col>.aggregate-function / .list-agg-delimiter keys (case 2 subset). Every other field-scoped option stayed on the old column name and was silently persisted: partial-update fields.<cols>.sequence-group (both key and value), fields.<col>.nested-key, ignore-retract / distinct, and the map shared-shredding keys — so a rename could silently change merge semantics or revert a shredded MAP column to the default layout.

This ports the remaining case 2 suffixes and case 3 of Java SchemaManager.applyRenameColumnsToOptions.

Brief change log

• case 2 (fields.<col>.<suffix>, value has no column names): the renameable suffix list grows from 2 to Java's full 7 — adds ignore-retract, distinct, map.storage-layout, map.shared-shredding.max-columns, map.shared-shredding.column-placement-policy.
• case 3 (fields.<col,col,...>.<suffix> for sequence-group / nested-key): rename exact, comma-separated matches in BOTH the key's field list and the value, mirroring Java's applyNotNestedColumnRename (whole-name match only — renaming price does not touch price2, order preserved).
• The drop path (remove_field_scoped_options) shares the case-2 suffix table, so dropping a column now also cleans up the newly covered keys.

Tests

• cargo test -p paimon --lib spec:: — 454 passed, including:
  • new unit tests: case-2 rewrites all 7 suffixes (value preserved, ab untouched when renaming a); case-3 rewrites key + value, unrelated options untouched.
  • new apply_changes tests: rename of a sequence-group key field and value field (fields.version,source_order.sequence-group=price,quantity -> fields.version,order_seq.sequence-group=amount,quantity), nested-key key + value, remaining case-2 suffixes incl. a MAP column, and whole-name matching.
  • existing test_rename_column_rewrites_field_scoped_agg_options unchanged and passing.
• cargo test -p paimon --lib — 2054 passed.
• cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings clean.

API and Format

No public API or storage format change; option keys are rewritten in place during schema evolution, matching Java metadata layout.

Documentation

No documentation change; code comments updated to reference the mirrored Java method.

---

🤖 Generated with Claude Code

Assumptions / notes for reviewers (per the repo AI-policy):

• The three map.* suffixes were added to Java's case-2 list after the issue text was written; included because Rust implements map shared-shredding (fields.<col>.map.storage-layout in arrow/shredding/map.rs), so renaming a shredded MAP column would otherwise strand the layout option.
• End-to-end tests carry sequence-group / nested-key / ignore-retract / distinct on tables without merge-engine, because Rust's create-time engine validation rejects those options (they arrive via Java-written metadata). Related pre-existing limitation, out of scope here: apply_changes re-runs create-mode validation, so ANY schema change on a Java-written partial-update table with sequence-group options is currently rejected — relaxing alter-time validation could be a follow-up issue.
• Chained renames (a->b plus b->c in one ALTER) apply sequentially per change, consistent with the existing case-1 handling (bucket-key / sequence.field); Java applies its rename map in one pass. This pathological case produces a different end state between the two implementations, same as case 1 today.