[WIP][core] Fix column masking correctness in query-auth reads

[plusplusjiajia]

Purpose

A cross-column mask (e.g. display := concat_ws('-', first, last)) throws at read time when the query projects the masked target but not the mask's input columns:

Column masking refers to field 'first' which is not present in output row type

Row-filter operands are already added to the read projection (#8447); this PR does the same for column-mask inputs, and hardens the paths that surfaced while testing it:

• Projection widening: TableQueryAuthResult.requiredAuthFields collects filter operands plus, transitively, the inputs of every mask whose target is readable. The widening appends missing table columns as-is
  (preserving nested pruning), the widened columns are projected back out after masking, and the scan pushes the widened read type before planning so file-level column pruning (e.g. data evolution) keeps the
  files those columns live in.
• Stale rules fail closed at plan time: rules referencing columns absent from the latest schema (e.g. after a rename/drop) are rejected once in AbstractDataTableScan.authQuery, the common path of every scan,
  re-validated only when the fetched rules change. Projected system fields (e.g. _ROW_ID) stay valid; unprojected ones, nested-pruned columns and blob-view columns are rejected.
• Read schema is fixed once the first split reader exists (split reads cache their format readers and ignore later read-type changes): every split is projected back to the query's read type, and masks apply
  only to columns readable from the query, so a column merely retained in a previously widened schema cannot activate a mask after a rules change. Previously the first createReader call mutated this.readType, so
  later splits of the same TableRead leaked the auth-added columns — also on the pre-existing row-filter path.
• Re-configuration fixes on the same path: MergeFileSplitRead.withReadType and DataEvolutionFileStoreScan.withReadType reset stale projections; IncrementalDiffSplitRead projects from the merge read's actual
  output type.

Behavior changes are scoped to query-auth.enabled tables; tables without query auth and the write path are unaffected.

Out of scope: raw-value pushdown on masked columns (filter/TopN/limit statistics pruning, masked partition predicates) is unsafe today on master for the already-merged masking feature. This PR does not change
any pushdown behavior; the fix is #8582 (stacked on this PR), where a predicate on a masked column evaluates on the masked value.

Tests

• MockRESTCatalogTest: cross-column masking with/without projecting the inputs, nested-pruning interaction, stale rules after rename/drop, system-field rules (projected and not), blob-view rejection, rules
  changing between reads of one TableRead, repeated reads.
• MergeFileSplitReadTest: repeated withReadType re-configuration; diff read over a projected merge read.
• TableQueryAuthResultTest: requiredAuthFields / appendMissingFields units.
• Engines: Flink RESTCatalogITCase and Spark SparkCatalogWithRestTest cross-column ITCases.

[JingsongLi]

• This PR addresses the projection of cross-column masks but explicitly does not handle the original value filtering/partition pruning/min-max/TopN/limit pushdown for masked columns.
• The results may be filtered by pre-desensitized values, reveal whether original values exist, or discard rows due to errors.
• The author has specifically addressed this issue in Draft [core] Keep raw-value pushdown off masked columns in query auth #8582. It is recommended that Pull Request [WIP][core] Fix column masking correctness in query-auth reads #8570 not be merged separately but at least processed in conjunction with [core] Keep raw-value pushdown off masked columns in query auth #8582.

[plusplusjiajia]

@JingsongLi Agreed. I'll fold the masked-column pushdown safety into this PR so masking is correct end to end in one place, and close #8582. Updating this PR shortly.