Reconnect replay reads the wrong Redis key

The whole point of this service is that a network blip must not silently drop notifications -- a guarantee that depends entirely on the backlog replay branch reading a user's stream of past notifications when a client reconnects with Last-Event-ID. It's currently reading from the pub/sub channel key instead, a key nothing ever writes stream entries to. Redis happily returns an empty result for a range query against a key that was never used as a stream, with no error at all -- so every reconnect-with-replay silently returns nothing, for every user, all the time. A user disconnected for even one second who missed a notification during that second never sees it, with no error, log line, or metric anywhere pointing at why.

The backlog replay branch reads from channel_key(user_id) -- the pub/sub channel name -- instead of stream_key(user_id), the key publish_event() actually XADDs backlog entries onto.

See practice_tickets/tests/test_ticket_10_replay_reads_wrong_redis_key.py: publish 2 notifications, then start event_stream() with last_event_id set to something before both of them -- the replay comes back empty despite both notifications genuinely existing in Redis.

stream_key and channel_key (app/keys.py) are two one-line functions that look almost identical and sit right next to each other throughout app/streaming.py and app/publisher.py -- reaching for the wrong one at a call site is an easy slip, and there's no type-level distinction between a stream key and a channel key that would catch it (they're both just str). Worse, a range query against a key of the wrong type, or one that doesn't exist, doesn't raise in Redis -- it just returns an empty list, identical to a user genuinely having no backlog.

Compare the key used in this replay call against the key used in publish_event()'s backlog write (app/publisher.py). They need to be the same key for the same user.