STATISTICS works for prepared SELECT, but not for the normal SELECT

**Describe the problem**

Please describe the issue you observed, and any steps we can take to reproduce it:

**To Reproduce**

Hi,

In the following test case, the prepared SELECT is equivalent to the normal SELECT. However, I found that the normal SELECT generates a query plan with more steps than that of the prepared SELECT. Based on the table `t1` is an empty table, so the filter in the query plan of the normal SELECT may be redundant. Given that prepared statements typically result in suboptimal query plans, the query plan generation process for normal SELECT statements may still have room for further optimization. If I remove the statement `CREATE STATISTICS s0 FROM t1;` then these two queries have the same query plan.

```
SET plan_cache_mode = force_generic_plan;
CREATE TABLE t1 (c0 BOOL CHECK (false), c1 INTERVAL, c2 STRING);
CREATE STATISTICS s0 FROM t1;
EXPLAIN ANALYZE SELECT ALL MAX((INTERVAL '-1012965135 year -366958859 months 1263074001 days -398365231 hours -1898892180 minutes 1329767033 seconds')) FROM t1 WHERE (NOT (((B'01010001001100110100010011011001100001001110001000101101100010101011001101011010110101101010110001100100000001010011000111101011111000110000110010011100010011010010110' < ALL (B'11101000100100100000110011110101111111000110111101000000101000101111011111101010110111011001010000001001010000001001010101010101110111111001010011110001110100111111011', B'11011111010011100000000000111010011100010001100000111011100011011110010010011000111110100110101101100001000101100110000000001110111000111000000001100010110000011001001'))) NOT BETWEEN SYMMETRIC (t1.c0) AND (((t1.c0) :::BOOL))));
info
-----------------------------------------------------------------------------------------------
planning time: 975µs
execution time: 837µs
distribution: local
plan type: custom

• group (scalar)
│ sql nodes: n1
│ execution time: 36µs
│ sql cpu time: 36µs
│ actual row count: 1
│ estimated row count: 1
│
└── • render
│ execution time: 6µs
│ sql cpu time: 6µs
│ actual row count: 0
│
└── • limit
│ count: 1
│
└── • filter
│ sql nodes: n1
│ execution time: 5µs
│ sql cpu time: 5µs
│ actual row count: 0
│ estimated row count: 1
│ filter: (c0 <= true) AND (c0 >= true)
│
└── • scan
sql nodes: n1
kv nodes: n1
KV time: 325µs
KV rows decoded: 0
sql cpu time: 21µs
actual row count: 0
estimated row count: 1 (100% of the table; stats collected 0 seconds ago)
table: t1@t1_pkey
spans: FULL SCAN (SOFT LIMIT)
(38 rows)

PREPARE prepare_query (interval, varbit, varbit, varbit) AS SELECT MAX($1) FROM t1 WHERE (NOT ((($2 < ALL ($3, $4))) NOT BETWEEN SYMMETRIC (t1.c0) AND (((t1.c0) :::BOOL))));
EXPLAIN ANALYZE EXECUTE prepare_query((INTERVAL '-1012965135 year -366958859 months 1263074001 days -398365231 hours -1898892180 minutes 1329767033 seconds'), B'01010001001100110100010011011001100001001110001000101101100010101011001101011010110101101010110001100100000001010011000111101011111000110000110010011100010011010010110', B'11101000100100100000110011110101111111000110111101000000101000101111011111101010110111011001010000001001010000001001010101010101110111111001010011110001110100111111011', B'11011111010011100000000000111010011100010001100000111011100011011110010010011000111110100110101101100001000101100110000000001110111000111000000001100010110000011001001');
info
---------------------------------------------------------------------------------------
planning time: 917µs
execution time: 262µs
distribution: local
plan type: generic, re-optimized

• group (scalar)
│ sql nodes: n1
│ execution time: 9µs
│ sql cpu time: 9µs
│ actual row count: 1
│ estimated row count: 1
│
└── • render
│ execution time: 3µs
│ sql cpu time: 3µs
│ actual row count: 0
│
└── • scan
sql nodes: n1
execution time: 1µs
sql cpu time: 1µs
actual row count: 0
estimated row count: 1 (100% of the table; stats collected 0 seconds ago)
table: t1@t1_pkey
spans

```

**Expected behavior**
The normal SELECT should be faster or same as the prepared SELECT.

**Additional data / screenshots**
If the problem is SQL-related, include a copy of the SQL query and the schema
of the supporting tables.

If a node in your cluster encountered a fatal error, supply the contents of the
log directories (at minimum of the affected node(s), but preferably all nodes).

Note that log files can contain confidential information. Please continue
creating this issue, but contact support@cockroachlabs.com to submit the log
files in private.

If applicable, add screenshots to help explain your problem.

**Environment:**
- CockroachDB version [CockroachDB CCL v26.2.0-alpha.00000000-dev-1ad60fb00289249b886bf98b08c8066e9475624e-dirty (x86_64-pc-linux-gnu, built 2026/02/03 03:00:41, go1.25.5)]
- Server OS: [Ubuntu 24.04]
- Client app [`cockroach sql`, JDBC]

**Additional context**
What was the impact?

Add any other context about the problem here.

Jira issue: CRDB-59526