kvserver/rangefeed: race-build iterator-recreation probability in CatchUpScan is loop-invariant

**Describe the problem**

Under race builds, `CatchUpScan` intends to recreate its iterator with ~25% probability at each new-key decision point. But the hash input is the address of the local `iter` variable ([catchup_scan.go#L271](https://github.com/cockroachdb/cockroach/blob/a7e117882b4356096b3a8ea26046baa7e5d53fce/pkg/kv/kvserver/rangefeed/catchup_scan.go#L271)), which is constant for the entire `CatchUpScan` call — it does not change when `iter` is reassigned after recreation. The result: roughly 25% of scans force recreation at *every* new key and 75% never force it, instead of an independent 25% chance per decision.

Test-coverage distribution skew only; no production impact (the hash path is gated on `util.RaceEnabled`).

**Suggested fix**

Mix in per-decision state, e.g. a counter incremented at each decision point, so consecutive decisions within one scan hash differently.

**Additional context**

Found during an agent-assisted correctness audit of the rangefeed subsystem. Code link is pinned to master @ a7e1178.

Jira issue: CRDB-65662

Start in pkg/kv/kvserver/rangefeed/catchup_scan.go at CatchUpScan and the race-build iterator recreation decision around line 271. Verify how the hash input behaves across successive new-key decisions, then update the decision state so recreation probability is independent per decision and confirm the race-build coverage distribution is no longer scan-wide.

Written by the indexing model from the issue text.