Live delivery crashes on a publisher/subscriber protocol mismatch

publish_event() writes the same logical notification to two different places with two different shapes: a Redis Stream entry that the replay path reads, and a pub/sub JSON message that the live path reads. Those two shapes have drifted apart, so every notification delivered while a subscriber is live-connected raises an unhandled error inside that subscriber's stream generator, aborting their connection mid-flight. This breaks the primary, common-case delivery path for all live traffic, and it's dangerously easy to miss in manual testing because reconnection replay works perfectly fine -- someone testing only Last-Event-ID replay would see it work great, right up until an actual live user has any notification published to them and their stream dies with no client-visible explanation.

publish_event() serializes a notification's event type into the pub/sub message under one key, but event_stream()'s live loop reads it back out under a different key that no longer exists in that dict, raising an unhandled error.

See practice_tickets/tests/test_ticket_12_live_delivery_protocol_mismatch.py: connect with no Last-Event-ID (pure live delivery, no replay involved at all), publish one notification, and read the next chunk -- it raises a KeyError instead of yielding the notification.

This is a protocol mismatch between two independent serializations of the same logical event, living in two different files, with nothing enforcing that they agree -- exactly the kind of drift that happens when one side of a two-sided contract gets touched without checking every consumer of the format on the other side. It's made harder to catch because the two paths that read a notification back (replay vs. live) don't share code and don't fail the same way: one works, one throws, and which one gets exercised first in testing determines whether anyone notices.

Compare the dict keys publish_event() puts into the pub/sub JSON message (app/publisher.py) against the dict keys event_stream()'s live loop reads back out of it (app/streaming.py). They describe the same three pieces of information -- a stream id, an event type, a data payload -- and need to agree on what each one is called.