feat(rabbitmq): public API for multi-node cluster endpoints (#2659)

[BlackChepo]

Summary

Adds public fluent API for RabbitMQ multi-node cluster failover. Closes #2659.

Wolverine's RabbitMQ transport already had the internal plumbing — RabbitMqTransport.AmqpTcpEndpoints is forwarded to
ConnectionFactory.CreateConnectionAsync(IList<AmqpTcpEndpoint>) (the official RabbitMQ.NET client failover API) — but no public way to populate the list. This PR exposes that capability through RabbitMqTransportExpression, propagates the configuration to virtual-host tenants, and surfaces the cluster nodes in connection diagnostics.

Public API

Two repeatable overloads on RabbitMqTransportExpression:

opts.UseRabbitMq(f =>
    {
        f.UserName = "guest";
        f.Password = "guest";
        f.Ssl.Enabled = true;
        f.Ssl.ServerName = "rabbit-cluster";
    })
    .AddClusterNode("rabbit-1.local")
    .AddClusterNode("rabbit-2.local")
    .AddClusterNode("rabbit-3.local");

• AddClusterNode(string hostName, int port = -1) — convenience overload. Copies ConnectionFactory.Ssl onto the new endpoint as a fresh SslOption so TLS configured on the factory applies to all cluster nodes by default. port = -1 defers to the AmqpTcpEndpoint constructor (5672 normal, 5671 TLS).
• AddClusterNode(AmqpTcpEndpoint endpoint) — power-user overload. Stores the supplied endpoint as-is. Use this for per-node TLS, distinct certificates, or non-default ports.

Both overloads require UseRabbitMq(...) or UseRabbitMqUsingNamedConnection(...) to have run first; a clear InvalidOperationException names both entry points.

Multi-tenancy

Virtual-host tenants (AddTenant(tenantId, virtualHostName)) inherit the parent transport's cluster nodes automatically — they target the same broker, so they should share
the cluster topology.

URI- and Action-based tenants (AddTenant(tenantId, Uri), AddTenant(tenantId, Action<ConnectionFactory>)) do not inherit the parent cluster — those overloads are for tenants on separate brokers and bring their own connection settings. This is a documented limitation; a future overload could accept cluster nodes for those paths if requested.

RabbitMqTenant.Compile() is guarded against duplicate appends on repeated calls.

Diagnostics

RabbitMqConnectionDescription gains indexed ClusterNodes[i] entries (formatted host:port) so the cluster configuration is visible in logs, resource reports, and OptionsDescription consumers. ResourceUri and RabbitMqHealthCheck semantics are unchanged — by design, since cluster failover means "any reachable node = healthy", not "all nodes individually reachable".

Out of scope

• Connection-string syntax for cluster nodes (ConnectionStringParser). Deferred until concrete demand and a clear format convention emerge. The fluent API is the only entry point for now.
• Per-tenant cluster configuration for URI/Action tenants. Documented limitation.

Test plan

• Unit tests for both overloads — argument validation, SSL inheritance (fresh instance, not shared reference), port = -1 default resolution, ordered append, AmqpTcpEndpoint overload preserves reference equality.
• Tenant inheritance — virtual-host tenants inherit, URI tenants do not (regression guard for the documented limitation), Compile() is idempotent.
• Diagnostics — ClusterNodes[i] entries render only when configured; empty list produces no entries.
• Integration smoke test — declares the local broker as a "cluster of one", publishes and receives a message via host.TrackActivity().PublishMessageAndWaitAsync(...), verifies traffic flows through CreateConnectionAsync(IList<AmqpTcpEndpoint>).
• Full RabbitMQ test suite (74 tests) — no regressions.
• Docs build — new "Connecting to a RabbitMQ cluster" section with TLS-inheritance and per-node override examples.