RabbitMQ Web-STOMP WebSocket Messaging Design Prompt

You are a senior platform engineer who has put RabbitMQ Web-STOMP in front of browser clients for real-time features (live dashboards, notifications, chat). Help me design this so untrusted browsers can subscribe to exactly what they're allowed to and nothing more.

I will provide:
- The use case and message flow: who publishes, who subscribes, expected concurrent browser connections, message rate per client [DESCRIBE]
- Auth model: how users authenticate to my app today (session, JWT, OAuth) and how identity should map to broker permissions [DESCRIBE]
- Topology: exchanges/queues that back the browser destinations, and whether browsers should ever publish or only subscribe [DESCRIBE]
- Deployment: TLS termination point, reverse proxy (nginx/Caddy) in front of `rabbitmq_web_stomp`, and vhost layout [DESCRIBE]

Your job:

1. **Map STOMP destinations to broker objects** — explain how `/exchange`, `/queue`, `/topic`, `/temp-queue`, and `/amq/queue` destinations resolve to RabbitMQ exchanges, queues, and routing keys, and choose the destination style that gives each browser its own isolated stream without leaking others' data.

2. **Never trust the browser for authorization** — design per-user credentials or a token-to-vhost/permission mapping so a client can only subscribe to its own destinations. Explain why STOMP `SUBSCRIBE` destinations must be validated server-side (a browser can send any frame), and how RabbitMQ topic authorization and per-user vhosts enforce scope rather than relying on client code.

3. **Handle connection identity and lifecycle** — cover how the browser presents credentials over Web-STOMP (login/passcode headers vs a short-lived token exchanged by your backend), heartbeat configuration for flaky mobile networks, and clean teardown so abandoned tabs don't leak connections and auto-delete/exclusive queues get reclaimed.

4. **Contain back-pressure and abuse** — a browser can subscribe and then stop reading. Design for it: per-connection prefetch, `max-length`/TTL on the auto-generated per-client queues so a slow consumer can't grow unbounded, connection and channel limits per user, and what happens when a client is blocked by a resource alarm.

5. **Secure the transport and edge** — require WSS (TLS), set the reverse-proxy WebSocket upgrade and timeout correctly, restrict origins, and decide whether Web-STOMP is exposed directly or only behind your proxy. Note the difference between authenticating the WebSocket and authorizing each STOMP frame.

6. **Plan observability and failure modes** — how to see browser connections (`rabbitmqctl list_connections` with the Web-STOMP protocol), what a dropped WebSocket looks like versus a STOMP-level error frame, and how clients should reconnect and re-subscribe without duplicating or missing messages.

Output as: (a) the destination + topology design with the authorization model spelled out, (b) the per-user permission/vhost scheme, (c) the queue-hygiene and back-pressure settings for browser-generated queues, (d) the edge/TLS/proxy configuration, and (e) the reconnect and observability plan.

Treat every browser as hostile input. Validate subscription destinations server-side and scope permissions per user before exposing Web-STOMP publicly — a misconfigured topic permission lets one user subscribe to every other user's stream.