sql: generic query plans do not push down parameterized limit

When a limit is parameterized, we cannot push it down into scans or other operators. This affects generic query plans, which explore before parameters are replaced.

Here's an example using `cockroach demo movr` on v24.2.0-rc.1:

```sql
-- custom plan has the limit pushed into the scan
EXPLAIN ANALYZE SELECT address FROM users ORDER BY city LIMIT 10;

SET plan_cache_mode = force_generic_plan;
PREPARE p AS SELECT address FROM users ORDER BY city LIMIT $1;
-- generic plan cannot push the limit down
EXPLAIN ANALYZE EXECUTE p (10);
```

Produces:

```
demo@127.0.0.1:26257/movr> EXPLAIN ANALYZE SELECT address FROM users ORDER BY city LIMIT 10;
info
--------------------------------------------------------------------------------
planning time: 363µs
execution time: 3ms
distribution: full
vectorized: true
plan type: generic, reused
rows decoded from KV: 10 (1.1 KiB, 1 gRPC calls)
cumulative time spent in KV: 3ms
maximum memory usage: 20 KiB
network usage: 0 B (0 messages)
regions: us-east1
sql cpu time: 92µs
isolation level: serializable
priority: normal
quality of service: regular

• scan
sql nodes: n1
kv nodes: n1
regions: us-east1
actual row count: 10
KV time: 3ms
KV contention time: 0µs
KV rows decoded: 10
KV bytes read: 1.1 KiB
KV gRPC calls: 1
estimated max memory allocated: 20 KiB
sql cpu time: 92µs
estimated row count: 10 (20% of the table; stats collected 14 minutes ago)
table: users@users_pkey
spans: LIMITED SCAN
limit: 10
(31 rows)

demo@127.0.0.1:26257/movr> EXPLAIN ANALYZE EXECUTE p (10);
info
-------------------------------------------------------------------------------------
planning time: 204µs
execution time: 1ms
distribution: full
vectorized: true
plan type: generic, reused
rows decoded from KV: 10 (1.1 KiB, 1 gRPC calls)
cumulative time spent in KV: 1ms
maximum memory usage: 20 KiB
network usage: 0 B (0 messages)
regions: us-east1
sql cpu time: 35µs
isolation level: serializable
priority: normal
quality of service: regular

• limit
│ count: 10
│
└── • scan
sql nodes: n1
kv nodes: n1
regions: us-east1
actual row count: 10
KV time: 1ms
KV contention time: 0µs
KV rows decoded: 10
KV bytes read: 1.1 KiB
KV gRPC calls: 1
estimated max memory allocated: 20 KiB
sql cpu time: 35µs
estimated row count: 50 (100% of the table; stats collected 15 minutes ago)
table: users@users_pkey
spans: FULL SCAN
(33 rows)
```

Also the explain shows `FULL SCAN` instead of `FULL SCAN (SOFT LIMIT)` for the scan.

Jira issue: CRDB-41155