Dead letter support (public facade).

This namespace is intentionally small and stable:
- It provides the public API (`DeadLetterProtocol`, `send-dead-letter!`, helpers)
- It *requires* all built-in sink implementations so Integrant can resolve their keys

## Protocol
- `d-core.core.messaging.dead-letter.protocol`

## Built-in implementations
- Logger sink: `d-core.core.messaging.dead-letter.sinks.logger`
- Storage sink: `d-core.core.messaging.dead-letter.sinks.storage`
- Producer sink: `d-core.core.messaging.dead-letter.sinks.producer`
- Common facade (sink selection/fallback): `d-core.core.messaging.dead-letter.common`

## Extending
Add a new sink under `d-core.core.messaging.dead-letter.sinks.*` and implement
`DeadLetterProtocol`. If you want it to be wired via Integrant, define a
`(defmethod ig/init-key ...)` in that namespace and ensure it gets required
(either by requiring this facade, or by requiring your sink namespace directly).

Dead-letter destination derivation.

This module provides transport-aware defaults so most topics do not need any
explicit DLQ topic configuration.

Convention (default): append `.dl` to the transport-specific destination name.

Helpers for enriching envelopes with standardized DLQ metadata.

The canonical location for DLQ state is:
- `[:metadata :dlq]`

This metadata is designed to be portable across sinks (logger/storage/producer)
and across replay mechanisms.

Dead-letter policy: classification + destination selection.

Policies decide:
- whether a dead-letter is eligible for auto replay vs stuck/poison/manual
- which sink to use (logger/storage/producer/hybrid)
- which destination to publish to (e.g. retry vs stuck DLQ topics)
- limits like :max-attempts / :delay-ms

The effective per-topic configuration is expected to be present on the envelope at:
- `[:metadata :dlq :deadletter]`
(populated by consumer runtimes).