kvserver/rangefeed: SeparatedIntentScanner.ConsumeIntents ignores the consumer stop signal

**Describe the problem**

`SeparatedIntentScanner.ConsumeIntents` discards the boolean returned by the `eventConsumer` callback ([task.go#L170](https://github.com/cockroachdb/cockroach/blob/a7e117882b4356096b3a8ea26046baa7e5d53fce/pkg/kv/kvserver/rangefeed/task.go#L170)). That return value exists so the scan stops when `sendEvent` fails because the processor stopped ([task.go#L75-L79](https://github.com/cockroachdb/cockroach/blob/a7e117882b4356096b3a8ea26046baa7e5d53fce/pkg/kv/kvserver/rangefeed/task.go#L75-L79)). Ignoring it means that after the processor stops mid-scan, the init resolved-timestamp scan keeps iterating the entire lock table and issuing sends into the void.

This cannot cause a false `Init`: `sendEvent` only returns false after `stopInternal` has been enqueued, and the subsequent `initRTS` event is never consumed by a stopping processor. The impact is wasted I/O/CPU on large lock tables and delayed shutdown, not a correctness violation.

**Suggested fix**

`if !consumer(...) { break }` (or return early) in `ConsumeIntents`.

**Additional context**

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

Jira issue: CRDB-65657

Start in pkg/kv/kvserver/rangefeed/task.go at SeparatedIntentScanner.ConsumeIntents and inspect how the eventConsumer callback relates to sendEvent. Ensure a false callback result stops the init resolved-timestamp scan; done means scanning no longer continues after the processor has stopped.

Written by the indexing model from the issue text.