[plusplusjiajia]

Purpose

On a table with query auth, operations that read rows and write data back did not respect the caller's row filter and column masks:

• Spark UPDATE, DELETE and MERGE INTO on append and Data Evolution tables find and read the candidate files through raw readers (newSnapshotReader and KnownSplitsTable). So UPDATE t SET note = ssn copied a masked column into a visible one, and rows hidden by the row filter were updated or deleted, for example DELETE FROM t without a condition.
• On primary-key tables, Spark and Flink UPDATE and MERGE INTO, and the Flink delete and merge-into actions, read the filtered, masked rows and wrote them back. Masked values were stored as real data, and masked keys could delete rows hidden by the row filter.
• Flink sort compaction and rescale, and Flink and Spark chain table compaction, read through the caller's filtered, masked view and overwrote partitions with it. The hidden rows were lost and the masks were stored.

These operations now fail when query auth gives the caller a row filter or a column mask. The check is a shared helper next to the search rejection, TableQueryAuthResult.rejectRewriteUnderQueryAuth, which authorizes with all columns and refuses when the result has rules. Users with full access are not affected, which matches PyPaimon, where update, delete, merge and index builds require full table access.

The check is called from:

• Spark: the UPDATE, DELETE and MERGE INTO commands (including Data Evolution tables and the Spark 4.0 merge commands), the V2 row-level operations, the optimized DELETE / truncate, and CompactChainTableProcedure;
• Flink: the row-level UPDATE / DELETE sink and the Delete, MergeInto, DataEvolutionMergeInto, SortCompact, Rescale and CompactChainTable actions.

Rewrites that read the raw files, such as the Spark sort compaction, clustering and rescale procedures, keep the data intact and are unchanged.

This builds on #10903, which stops a dynamic query-auth.enabled=false from turning query auth off; without it the check here can be bypassed the same way.

Tests

• SparkCatalogWithRestTest#testRowLevelOperationsRequireFullTableAccess: Spark UPDATE, DELETE and MERGE INTO are refused for a restricted user on append tables (with V1 and V2 writes, and with deletion vectors), primary-key tables and Data Evolution tables, and still work with full access.
• RESTCatalogITCase#testRowLevelOperationsRequireFullTableAccess and #testMaintenanceRewritesRequireFullTableAccess: Flink row-level operations, sort compaction and rescale are refused for a restricted user and still work with full access.
• RESTCatalogITCase#testRowLevelActionsRequireFullTableAccess: the Flink delete and merge-into actions are refused for a restricted user on primary-key and Data Evolution tables without changing the data or creating a snapshot, and still work with full access.
• The chain table compaction checks are not covered by a REST test yet: the existing chain table tests do not run on the REST catalog.
• The new Spark cases fail on master. The related tests pass locally, including the existing Spark and Flink query auth, row-level, merge-into and compaction suites. Spark 3, Spark 4 and Flink 1 compile without the fast-build profile.