Parquet: tolerate mixed row-group ordinal metadata on read

[zhuqi-lucas]

Which issue does this PR close?

• Closes [Parquet] Restore pre-#8715 tolerance for mixed row-group ordinal metadata (or add a lenient reader flag) #10381.

Rationale for this change

RowGroup.ordinal is optional in the parquet-format Thrift spec with no uniformity requirement, but since #8715 the reader hard-errors on files whose row groups disagree on whether it is populated (Inconsistent ordinal assignment: ...). Such files are produced in the wild (e.g. Go parquet writers flushing row groups incrementally) and were readable before 57.1.

This implements the plan agreed on the issue with @alamb, @etseidl and @vustef:

• All ordinals present → honor them as written.
• None present → sequential-fill at decode time, unconditionally — not just when row numbers are enabled — so downstream consumers behave identically whether the metadata was decoded fresh or reused from a prior read (the metadata-reuse hazard @vustef pointed out).
• Mixed → leave the metadata untouched. Positional backfill could disagree with the ordinals that are present, and a partial backfill would make row-number results depend on which row groups a query happens to select. Instead, consumers that require complete ordinals fail deterministically; plain reads succeed.

What changes are included in this PR?

• thrift/mod.rs: replace the per-row-group OrdinalAssigner (which errored on the first inconsistency) with a post-decode ensure_row_group_ordinals implementing the three cases above.
• array_reader/row_number.rs: RowNumberReader::try_new rejects mixed-ordinal files up front — even when every selected row group carries an ordinal — so row numbering for a given file either always works or always fails, regardless of row-group pruning (@vustef's determinism concern).
• thrift/encryption.rs: the encrypted column-metadata path used rg.ordinal.unwrap() for the AAD; with mixed metadata now reaching this code, return a proper error instead of panicking (@etseidl's encryption concern — files with fully-populated or fully-missing ordinals are unaffected).

Are these changes tested?

• Decode round-trip tests for all three shapes (honored / sequential-filled / left untouched), including the exact Go-writer shape from the issue (first row group missing the ordinal). The mixed cases fail on main with the Inconsistent ordinal assignment error.
• RowNumberReader unit tests: mixed metadata errors even for an ordinal-only selection; all-missing metadata errors for any selection.
• End-to-end test: a real 4-row-group file with one ordinal stripped reads fine without virtual columns and fails deterministically with the row-number column, even when selecting only row groups that carry ordinals.
• Full parquet test suite passes with --all-features.

Are there any user-facing changes?

Files with mixed or absent row-group ordinal metadata are readable again (as before 57.1). Row-number virtual columns keep their strict guarantee: they now fail deterministically per file instead of depending on row-group selection. No API changes.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.