feat(redis): named-broker and broker-per-tenant support (GH-3309)

[jeremydmiller]

Closes #3309

Brings the Redis Streams transport (Wolverine.Redis) up to parity with RabbitMQ / NATS on the two established multi-broker features. It had neither before.

Feature 1 — Named broker

• RedisTransport now stores an instance Protocol (heaviest part of this change): protocol-carrying constructors for every connection source, and all endpoint-URI construction + scheme checks (buildStreamCache, ResourceUri, findEndpointByUri, tryBuildSystemEndpoints, RedisHealthCheck) use it instead of the hard-coded "redis" literal. A named broker's endpoints therefore carry the broker name as their URI scheme (secondary://stream/0/orders) and never collide with the default redis:// broker.
• AddNamedRedisBroker(BrokerName, …) with connection-string / ConfigurationOptions / IConnectionMultiplexer / factory overloads. Because Redis needs connection info, it constructs new RedisTransport(name.Name, …) and Transports.Add(...) directly rather than relying on GetOrCreate's reflective ctor.
• ListenToRedisStreamOnNamedBroker / ToRedisStreamOnNamedBroker pin endpoints to a named broker (throws a helpful error if the broker wasn't registered first).

Feature 2 — Broker-per-tenant (modeled after NATS)

• New RedisTenant — a dedicated, lazily-built IConnectionMultiplexer per tenant (connection string / ConfigurationOptions / caller-managed multiplexer). RedisTransport.Tenants + GetTenantConnection; eager connect+ping in ConnectAsync; disposal in DisposeAsync of only the multiplexers Wolverine built itself.
• AddTenant(tenantId, …) + ConfigureMultiTenancy(TenantedIdBehavior) on the expression.
• CreateSender fans out to a framework TenantedSender, routed by Envelope.TenantId; BuildListenerAsync builds a CompoundListener with one listener per dedicated-connection tenant wrapped in ReceiverWithRules + TenantIdRule. The sender/listener take an optional tenant multiplexer and target their own database on it. Tenant listeners provision their consumer group on their own server.

GH-2361

Both the tenant senders and the default fallback under TenantedSender are the fire-and-forget InlineRedisStreamSender — not BatchedSender + RedisSenderProtocol. TenantedSender doesn't forward RegisterCallback, so a callback-requiring sender under it would silently drop every message. Verified by the inbound tenant round-trip test (a silent drop would surface as a timeout).

Tests

• RedisNamedBrokerRegistrationTests (no broker; always runs in CI) — distinct transport per broker, endpoints use the broker name as scheme, unregistered-broker throws.
• RedisNamedBrokerTests + RedisPerTenantConnectionTests — spin up a second Redis container (server B) via a shared IClassFixture; raw XREAD proves a …OnNamedBroker / TenantId-tagged message lands on server B (and a default on server A), plus an inbound round-trip stamped with the broker scheme / tenant id.
• Full Wolverine.Redis.Tests green (131 passed). dotnet build wolverine.slnx -c Release clean (0 warnings, 0 errors).

Docs

Added "Connecting to Multiple Brokers" and "Multi-Tenancy" sections to docs/guide/messaging/transports/redis.md with compiling snippet samples; reverted unrelated mdsnippets churn.

Caveats

• Each tenant is an independent Redis server, so the same stream key + consumer group are created separately per tenant multiplexer — no collision (dedicated multiplexer per tenant is the spec, not shared-server-different-DB).
• The two integration test classes need a second Redis container, so they skip cleanly when Docker is unavailable.

🤖 Generated with Claude Code