P1 — A blocked multi-stream read returns only one stream when several become ready together

The wake path resolves only `Transaction::GetWakeKey()` (`stream_family.cc:3139-3142`) and
builds a reply with cardinality exactly one (`stream_family.cc:3221-3229`). The root cause
is in the transaction layer: `NotifySuspended` claims a once-only blocking barrier and
records a single wake key (`transaction.cc:1578`, `1598`), so the woken command
structurally cannot see that several keys became ready — a fix needs to re-scan all
requested streams on wake, as Valkey's unblock reprocessing does. Pre-existing bug, not
introduced by #8047.

Scenario (single shard for determinism):

```text
XGROUP CREATE s1 g 0 MKSTREAM
XGROUP CREATE s2 g 0 MKSTREAM

# client A
XREADGROUP GROUP g c BLOCK 0 STREAMS s1 s2 > >

# client B
MULTI
XADD s1 1-0 f one
XADD s2 1-0 f two
EXEC
```

Actual: the reply contains only one stream (e.g. `s2`), and only that stream gets PEL
treatment; `XPENDING s1 g` stays empty. The omitted entries are not lost (last-delivered
on `s1` is unchanged, a later `>` read retrieves them), but the reply is incomplete vs
Valkey and the PEL is asymmetric. Plain blocked `XREAD` has the same single-stream reply,
without the PEL aspect.

Reproduce the single-shard scenario with blocked XREADGROUP, MULTI, XADD to both streams, and EXEC. Read the wake path in stream_family.cc:3139-3142 and 3221-3229, then trace NotifySuspended in transaction.cc:1578 and 1598. Done means a blocked read re-scans all requested streams that become ready together, returns both streams, and applies PEL treatment symmetrically.

Written by the indexing model from the issue text.