Summary:
Under row-level security, match_clause_to_index rejects a clause as an
index qual through restriction_is_securely_promotable when the clause
has a security level above the relation's minimum and is not leakproof.
yb_indexcol_can_merge_scan scans baserestrictinfo independently and had
no such gate, so a non-leakproof stream SAOP (for example, one whose
LHS contains yb_hash_code) was still chosen for merge scan.  The plan
advertised merge streams while the SAOP was demoted to a filter, the
stream column was never bound, and the scan silently returned zero
rows (see related issue #32735).

Fix by aligning the logic so the planner does not pick merge streams
from conditions that RLS keeps out of the index conditions.

Test Plan:
On Almalinux 8:

    ./yb_build.sh fastdebug --gcc15 daemons initdb \
      --no-ybc --skip-pg-parquet --no-odyssey \
      --java-test TestPgRegressMergeScan

The new yb.orig.merge_scan_rls test fails without the code change (the
RLS-subject non-leakproof SAOP query plans a merge scan without an
index condition, Merge Streams: 3 with the SAOP under Filter, and
returns zero rows) and passes with it.

Backport-through: 2025.2

Reviewers: gkukreja

Reviewed By: gkukreja

Subscribers: yql

Differential Revision: https://phorge.dev.yugabyte.com/D56014