opt: missing rule to add hard limits to skip-locked scan with new lock operator

With the old lock operator, we're able to produce a single Scan operation that has a hard limit for a limited SELECT FOR UPDATE SKIP LOCKED:

```sql
CREATE TABLE a (a INT PRIMARY KEY);
EXPLAIN SELECT a FROM a ORDER BY a LIMIT 1 FOR UPDATE SKIP LOCKED;
-- • scan
-- missing stats
-- table: a@a_pkey
-- spans: LIMITED SCAN
-- limit: 1
-- locking strength: for update
-- locking wait policy: skip locked
```

But if we use the new lock operator, we have a separate Limit on top of the Scan operation. This is less optimal, as some of the time it will lock too many rows.

```sql
SET optimizer_use_lock_op_for_serializable = on;
EXPLAIN SELECT a FROM a ORDER BY a LIMIT 1 FOR UPDATE SKIP LOCKED;
-- • limit
-- │ count: 1
-- │
-- └── • scan
-- estimated row count: 1
-- table: a@a_pkey
-- spans: FULL SCAN (SOFT LIMIT)
-- locking strength: for update
-- locking wait policy: skip locked
```

I wonder if this has something to do with the PushLimitIntoLock normalization rule added in #127718?

Jira issue: CRDB-64371

Epic CRDB-65887