Pub/sub connection leaks when subscribe() fails

Every event_stream() call creates a pubsub object that holds a connection from the underlying Redis connection pool. If subscribing raises -- a transient Redis blip, a connection reset, anything -- while a client happens to be connecting at that exact moment, the pubsub object and the connection it holds are never closed, and each such failure permanently removes one connection from the pool. This is invisible under normal conditions, but under sustained connection churn with intermittent Redis instability -- exactly the conditions a real production Redis experiences during a failover -- it accumulates until the pool is exhausted and every new stream request, even healthy ones, starts failing or hanging, with a full restart the only way to recover.

pubsub.subscribe(channel) is called before the try/finally block that would otherwise close the pubsub object, so if it raises, the finally block that calls pubsub.aclose() is never reached and the connection it was holding is never released back to the pool.

See practice_tickets/tests/test_ticket_13_pubsub_leak_on_subscribe_failure.py: use a fake Redis client whose pubsub().subscribe() always raises, call event_stream(), catch the resulting exception, and check whether the pubsub's close method was ever called -- it wasn't.

This is a resource-cleanup-ordering bug, not a logic bug -- every individual line is doing something reasonable, but the order (acquire resource, do a thing that can fail, guard cleanup only from that point onward) leaves a gap between resource acquired and cleanup guaranteed that a failure landing in exactly that gap slips through. It's the same shape of bug as a file handle opened before a try instead of inside it -- unremarkable individually, and only a real problem under the specific failure timing production eventually produces and a quick manual test essentially never does.

Everything from pubsub = redis.pubsub() onward needs the guarantee that however far setup gets before failing, pubsub.aclose() still runs. Think about how much of the current setup sequence needs to move inside the try block -- and how much of the finally block needs to stop assuming setup fully succeeded, since it currently unconditionally calls unsubscribe(), which itself assumes subscribe() succeeded.