perf(stream): trim with a single DeleteRange instead of per-entry Delete (#3592)

### Problem

`Stream::trim()` — the shared path behind `XTRIM` and `XADD` with
`MAXLEN`/`MINID` — removes trimmed entries one at a time: a per-entry
`WriteBatch::Delete()` in a loop, committed as a single atomic batch.
This makes trimming **O(entries removed)**:

- Removing a large number of entries builds a correspondingly large
write batch of point tombstones and commits it in one atomic write.
- Those point tombstones are then scanned one-by-one by every reader,
and re-scanned by each subsequent trim's `Seek`.

For a stream that is trimmed continuously (each trim removes many
entries), this is expensive both on the write and on subsequent
reads/trims.

### Change

Replace the per-entry `Delete()` loop with a single
`WriteBatch::DeleteRange()` over the trimmed span — the same approach
already used for bulk deletion in `DestroyGroup()`.

- The entries are still scanned to count them, so `metadata` (`size`,
`first_entry_id`, `max_deleted_entry_id`) is maintained exactly as
before and `XLEN` stays exact. Only the deletion mechanism changes: the
write batch stays O(1) (one range tombstone) instead of O(entries
removed).
- Group, consumer and PEL subkeys are encoded with a `UINT64_MAX` prefix
and sort after every entry key, so they always stay outside the deleted
range. The exclusive upper bound is the first surviving entry for a
partial trim, or the next-version prefix when the whole stream is
trimmed.

### Tests

Adds cases for the behaviour specific to the range delete, alongside the
existing trim suite:

- consumer group + PEL survival across a full-entry trim,
- entries added after a trim-to-empty remaining visible (range-tombstone
sequence-number semantics),
- repeated `MINID` trims interleaved with adds keeping exact survivors
and first/max-deleted bookkeeping.

---------

Co-authored-by: hulk <hulk.website@gmail.com>