Fix RabbitMQ transport startup and shutdown lifecycle bugs

[Vulthil]

Summary

Three fixes to the RabbitMQ transport's start/stop lifecycle, all triggered by the startup-retry loop that retries a broker that isn't up yet:

1. Doubled consumers or a stuck retry loop on transient startup failure. If a retry attempt failed after topology setup but during consumer-channel creation, the next retry re-registered every queue's handlers on top of the ones already registered — silently doubling dispatch for plain consumers, and making any RPC consumer fail forever with a misleading "already has a request consumer" error. The registry is now rebuilt fresh at the start of every attempt instead of being kept as long-lived instance state.
2. Host shutdown mid-delivery was treated as a consumer failure. Cancelling a delivery because the host is shutting down went through the same failure path as a real exception — republishing to the retry queue or publishing a fault, then acking/nacking a message that was simply interrupted. The standard consume path now leaves such deliveries unsettled for the broker to requeue, matching the in-memory retry path's existing behavior.
3. A broker that's unreachable at startup could crash the host before the retry loop ever ran. The hosted service resolved its transport eagerly in its constructor, which for the RabbitMQ transport meant establishing the broker connection — if that failed, the host faulted during service construction, never reaching the retry loop that exists specifically to handle this case. The transport is now resolved lazily, inside the retry loop, while the "no transport is configured" error still surfaces immediately and clearly at host startup.

No public API changes — all touched types are internal.

Test plan

• Full solution dotnet build (SonarAnalyzer + TreatWarningsAsErrors gate) — 0 warnings, 0 errors
• Vulthil.Messaging.Tests — 98/98 passing
• Vulthil.Messaging.RabbitMq.Tests — 64/64 passing
• Vulthil.Messaging.Abstractions.Tests — 14/14 passing
• Vulthil.Messaging.TestHarness.Tests — 16/16 passing
• New regression tests for fixes 1 and 2 confirmed failing on the unfixed code before the change, passing after
• Existing no-transport startup-error test and TestHarness transport-replacement tests remain green

Backport to v1.0: recommended — internal-only fixes for defects present since 1.0.0.

[Vulthil]

Successfully created backport PR for v1.0:

• [Backport v1.0] Fix RabbitMQ transport startup and shutdown lifecycle bugs #285