fix(spec): validate sequence.field against table schema

[jackylee-ch]

Purpose

Creating a table with sequence.field referencing a column that does not exist was silently accepted. The write path then resolved sequence fields with a lenient lookup and fell back to the auto-increment sequence, so merge results ignored the user's ordering intent instead of failing loud. Repeated fields and merge-engine=first-row were likewise unchecked.

Brief change log

• Add Schema::validate_sequence_field, mirroring Java SchemaValidation#validateSequenceField: every listed field must exist in the schema, must not be listed more than once, and merge-engine=first-row rejects user-defined sequence fields.
• Wire it into both the create path (Schema::new) and the alter path (TableSchema::apply_changes).

Tests

• test_create_schema_rejects_unknown_sequence_field, test_create_schema_rejects_repeated_sequence_field, test_create_schema_rejects_sequence_field_with_first_row, test_alter_set_unknown_sequence_field_rejected.
• cargo test -p paimon --lib, cargo clippy -p paimon --all-targets -- -D warnings, cargo fmt --all -- --check pass.

API and Format

No API or storage format change; only rejects schemas that already violate the sequence.field contract.

Documentation

No documentation change required.

[JingsongLi]

Claims to be aligned with Java’s validateSequenceField, but omits validation for cross-partition updates. sequence.field can still be configured even when not all partition keys are included in the primary key, whereas Java explicitly rejects this combination. Both the create and alter paths should include partition keys and primary keys in the validation.