Decide future of RabbitMQ delayed-message-exchange usage in Brighter

## Context

PR #4104 upgrades the test image to RabbitMQ 4.2 + delayed-message-exchange plugin `v4.2.0-rc.1`. This is the **terminal working combination**:

- Team RabbitMQ archived [`rabbitmq-delayed-message-exchange`](https://github.com/rabbitmq/rabbitmq-delayed-message-exchange) on 2026-01-29.
- The plugin is built on Mnesia, which RabbitMQ 4.3 removed entirely (Khepri-only). The plugin therefore cannot work on 4.3+.
- `v4.2.0-rc.1` is a release candidate; no stable 4.2 release will ever ship.

Brighter's RMQ transports expose `Exchange.SupportDelay = true` as the opt-in for this plugin (see [`ExchangeConfigurationHelper.cs`](https://github.com/BrighterCommand/Brighter/blob/master/src/Paramore.Brighter.MessagingGateway.RMQ.Async/ExchangeConfigurationHelper.cs)). When the flag is `false`, [`RmqMessageConsumer.RequeueAsync`](https://github.com/BrighterCommand/Brighter/blob/master/src/Paramore.Brighter.MessagingGateway.RMQ.Async/RmqMessageConsumer.cs#L419) already falls back to a producer-side `SendWithDelayAsync` path that uses `IAmAMessageScheduler`. Brighter ships six scheduler implementations: AWS, AWS.V4, Azure, Hangfire, Quartz, TickerQ.

## Question

What should Brighter's long-term story be for delayed messaging on RabbitMQ?

## Options under consideration

A — **Stay on RMQ 4.2 + plugin**. Status quo after #4104 is merged. Locks the test broker (and any user opting into `SupportDelay`) at RMQ 4.2 forever.

B — **Drop the plugin path; rely on `IAmAMessageScheduler` fallback**. Brighter already implements this for `SupportDelay = false`. Effectively means deprecating `Exchange.SupportDelay` and steering users to a registered scheduler.

C — **Implement TTL + DLX in the RMQ transport** (per-queue or per-message TTL, dead-lettered on expiry). RabbitMQ-native but per-message TTL has [head-of-line blocking](https://www.rabbitmq.com/docs/ttl); per-queue TTL needs delay buckets.

D — **Adopt VMware Tanzu RabbitMQ's `rabbitmq_delayed_queue` plug-in**. Official replacement, Raft-based, scales to 10⁸ messages — but commercial Broadcom license. OSS users excluded.

E — **Mark `Exchange.SupportDelay` `[Obsolete]` and remove next major**. Aligns with upstream signal.

## Deliverable

A separate PR will land an ADR (under `docs/adr/`) that fully analyses these options with cost/benefit, migration paths, and a recommendation. This issue tracks the decision; comments on direction are welcome here or on the ADR PR.

## Related

- PR #4104 — the 4.2 upgrade (terminal version)
- Plugin archival:
- Tanzu replacement: [delayed queues docs](https://techdocs.broadcom.com/us/en/vmware-tanzu/data-solutions/tanzu-rabbitmq-ova/4-2/tanzu-rabbitmq-ova-virtual-machine/site-delayed-queues.html)
- RabbitMQ 4.3 release notes (Mnesia removed):

Start with ExchangeConfigurationHelper.cs and RmqMessageConsumer.cs, then review PR #4104 and the existing IAmAMessageScheduler implementations. The separate ADR under docs/adr/ should compare the listed options, migration paths, and operational trade-offs. Done means the project has an agreed long-term RabbitMQ delayed-messaging direction documented in the ADR.

Written by the indexing model from the issue text.