Load-balance responders across processes using Core NATS queue groups for request-reply

Steps

1. Have each responder process create a subscription on the same subject and the same queue group name (e.g. all instances subscribe to 'orders.process' with queue name 'order-workers')
2. NATS automatically load-balances: for each published message, the server delivers to exactly one randomly chosen member of the queue group, not to all of them
3. For request-reply, have the requester use the standard request API on the subject; only one queue-group member replies, since only one receives the request
4. Scale out by simply starting more responder processes subscribed to the same subject/queue name — no server-side configuration is required, queue groups are purely client-driven
5. Scale down gracefully by having a responder drain (unsubscribe cleanly) before shutting down so in-flight requests complete rather than being dropped mid-processing
6. Combine multiple queue groups on the same subject if you need both a load-balanced worker pool and a separate set of subscribers each seeing every message (queue subscribers vs. plain subscribers coexist on the same subject)