I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

Enable Row Access Policy (RAP) predicates to participate in storage-level pushdown optimizations (range pruning, bloom pruning, prewhere row selection) instead of being enforced only by a post-scan Filter [SECURE] operator.

Previously, secure predicates were merged into a single combined filters field in PushDownInfo, which made them invisible in EXPLAIN and prevented fine-grained control. This PR separates them into a dedicated secure_filters field, uses effective_filters() to combine them at the storage layer for pruning, and introduces has_secure_predicates_not_applied_by_prewhere() as the safety gate for limit/sort pushdown.

Changes

Optimizer

• RulePushDownPrewhere now matches bare Scan nodes (not just Filter -> Scan) and pushes secure predicates into prewhere via secure_prewhere_optimize().
• Limit/sort pushdown rules (RulePushDownLimitScan, RulePushDownSortScan, RulePushDownLimitFilterScan, RulePushDownSortFilterScan) use has_secure_predicates_not_applied_by_prewhere() instead of blanket bail-out.

Physical plan

• PushDownInfo gains a secure_filters: Option<Filters> field, kept separate from user filters for display redaction.
• effective_filters() combines user + secure filters with AND for storage-layer consumption (range pruner, bloom pruner).
• is_deterministic is now derived from individual user/secure computations instead of a redundant combined call.

Storage

• FusePruner and read_partitions use effective_filters() for range/bloom pruning, ensuring RAP expressions participate in block-level index pruning.
• TopN/limit pruning guards check secure_filters.is_none() to maintain correctness (same behavior as with regular WHERE filters).

Display

• EXPLAIN shows secure_filters: REDACTED to indicate RAP participation without leaking policy expressions.
• Filter [SECURE] pipeline operator is retained as the final enforcement layer.

Other

• ResultCacheWriter::append_block calls maybe_gc() to reclaim memory from filtered blocks before caching.

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

This change is