An event bus inside one process.

For development, for tests, and for an application that has modules but not
yet servers. It implements the same protocols as the Redis adapter so that
moving between them is configuration — but it is not a smaller version of
it: events do not leave the process, and history dies with it.

Delivery is asynchronous here even though it need not be. A bus that
delivers on the publisher's thread lets a caller depend on the handler
having finished by the time `publish!` returns, and that assumption then
fails silently against Redis. Matching the weaker guarantee is what makes
the adapters interchangeable.

An event bus over Redis Streams.

Streams rather than Redis pub/sub, and the difference is the whole reason
this is usable. Pub/sub is fire-and-forget: a subscriber that is restarting
when an event is published never learns it happened, and there is no way to
find out afterwards. A stream keeps its entries, hands each consumer group
its own cursor, and tracks what has not been acknowledged — which is what
makes at-least-once possible at all.

At-least-once, specifically: an event is delivered until a consumer
acknowledges it, so a consumer that crashes mid-handler sees the event again
when it comes back. Consumers must be idempotent. `:id` on the envelope is
there for that — it is assigned by the publisher, so it is the same across
redeliveries, unlike the stream entry id.