Decide whether to support Redis Cluster #66

TimersBroker rejects a RedisCluster client outright today — there is a check at construction
and tests/test_unit.py::test_broker_rejects_redis_cluster_client pins that behaviour. FastStream
0.7 shipped a RedisClusterBroker, so the framework-side story now exists, and the FastStream 0.7
migration listed cluster support as out of scope and deferred.

The reason the rejection exists is not incidental. Every timer topic is backed by a pair of
keys, {timeline_key}:{full_topic} and {payloads_key}:{full_topic}, and both the claim and the
commit Lua scripts operate on both keys in one call. Under Cluster those two keys hash to different
slots unless the key names are reshaped with hash tags, so the scripts would be rejected as
cross-slot. Supporting Cluster therefore means changing the key derivation — a wire-format change
for anyone with timers already persisted in Redis — plus deciding how cancel_all's two-key
UNLINK pipeline behaves across slots. That is its own design, which is exactly why it was pushed
out of the 0.7 migration rather than tacked onto it.

The issue to settle is whether the package should support Cluster at all, and if so whether hash
tags are introduced with a read-side migration path for existing timers (the same one-way shape the
legacy envelope fallback uses) or as a hard break in a major version.

Revisit trigger: a user reports that they run Redis Cluster and cannot adopt the package, or
FastStream's own RedisClusterBroker becomes the mainstream way its Redis integrations are
deployed. Until one of those, the explicit rejection with a clear error is the right behaviour and
this stays closed as "won't do for now".

Origin: planning/changes/2026-06-03.01-faststream-0.7-migration.md, "Out of scope (deferred to
follow-up specs)".