Per-thread realtime: replace the event stream with SignalR

ChannelRuntimeEventStream broadcasts a single undifferentiated firehose. With
multiple threads in flight, the portal needs to know which thread an event belongs to
— and must not receive other people's events at all.

What to build

• A SignalR hub replacing IRuntimeEventStream's transport. Keep the interface;
  change what is behind it, so callers do not all have to be rewritten at once.
• Groups per thread. A client subscribes to the threads it is allowed to see.
• Groups per owner for things that are not thread-scoped (a session starting, a
  desk image finishing).
• Authorise on connect using the same principal resolution as the HTTP gate. An agent
  token must not be able to subscribe to a human's threads.
• Reconnect with backfill: on reconnect, a client should be able to ask for what it
  missed rather than silently losing events.

Why now rather than later

The portal is multi-threaded from its first screen. Building it against a firehose and
filtering client-side would mean every client receiving every user's events, which is
the same disclosure bug #30 fixed on the HTTP side.

Acceptance

Two owners connected at once receive only their own events, asserted by a test. The
existing panel keeps working throughout the migration.

Start with IRuntimeEventStream and ChannelRuntimeEventStream to understand the current transport and how the existing panel uses it. Review the HTTP gate's principal resolution before mapping thread and owner subscriptions. Done means the panel continues working, reconnect backfill is supported, and a test shows two owners receive only their own events.