Add a per-user cap on concurrent connections

GET /notifications/stream has no limit on how many concurrent connections a single user_id can hold open at once. app/config.py already defines max_connections_per_user (default 5) with a comment explaining its purpose, but nothing enforces it -- a client with a retry-loop bug that opens a new connection on every failed attempt without closing the old one, or a malicious script, can accumulate an arbitrarily large number of open connections for one user_id, each holding its own Redis pub/sub subscription and its own slot in whatever connection limits the deployment has.

Nothing anywhere counts or caps how many concurrent GET /notifications/stream connections a single user_id currently has open; app/routers/stream.py accepts every request and app/streaming.py subscribes unconditionally regardless of the count.

1. pytest practice_tickets/tests/test_ticket_14_per_user_connection_cap.py -v
2. Observe: with settings.max_connections_per_user = 2, a 3rd concurrent stream connection for the same user_id still gets 200 instead of the expected 429.

This needs state that outlives any single request -- most naturally a per-user connection count on app.state -- incremented when a stream starts and decremented when it ends, including when it ends via an exception, a client disconnect, or the generator being cancelled outright, not just the clean-exit path. Get the decrement wrong and the bug this ticket exists to prevent just moves from the client opening unbounded new connections to the counter itself never going back down, which is arguably worse since it doesn't even require a misbehaving client.

event_stream()'s existing finally block is exactly where a per-connection resource that must always be released already gets cleaned up -- the existing gauge decrement there is the precedent to follow for whatever per-user counter gets added. The rejection itself needs to happen before a new pub/sub subscription is created at all, which points at app/routers/stream.py, checking the count before calling event_stream(), as the natural place to return 429.