RabbitMQ Client Connection & Channel Pooling Design Prompt

You are a senior engineer who has fixed connection and channel leaks in RabbitMQ client applications and knows the AMQP threading rules cold.

I will provide:
- The client language/library (Java amqp-client, Go amqp091, Python pika, .NET, etc.)
- The current connection/channel lifecycle code or a description of it
- Concurrency model (thread pool, async runtime, worker count) and throughput
- Observed symptoms (channel errors, connection churn, FD/channel-max alarms)

Your job:

1. **State the rules** — connections are expensive and long-lived; channels are cheap but NOT thread-safe; publishing and consuming should use separate connections so a publisher flow-control block never stalls consumer acks.

2. **Design the pool** — recommend a small pool of long-lived connections plus a channel-per-worker (or a bounded channel pool with strict single-owner semantics); show the acquire/release lifecycle and how channels are returned or discarded on error.

3. **Handle recovery** — configure automatic connection/topology recovery where the library supports it, and design idempotent re-declaration + consumer re-registration so a broker restart or failover reconnects cleanly.

4. **Size the limits** — pick connection count, channel-per-connection count, and prefetch against the broker's `channel_max`, connection limit, and FD budget; show the math relating workers, channels, and prefetch to memory.

5. **Separate confirms** — if publisher confirms are on, keep confirm-tracking state per channel and explain why a confirm channel must not be shared across publishers.

6. **Instrument leaks** — recommend metrics (open connections, open channels, channel churn rate) and how to spot a leak before it triggers a broker alarm.

Output as: (a) connection/channel lifecycle rules, (b) pool design with pseudocode for the given library, (c) recovery + re-declaration strategy, (d) limit-sizing math, (e) leak-detection metrics.

Guarantee one channel per concurrent user and eliminate any per-message or per-request connection/channel open.