UISIs Observability

## Requirement

on observability: i was imagining that observed clients could phonehome all chunks of e2ee activity as structured activity to jaeger \(ie the coarse operations the client is doing to the keys, devicelist updates, keyshare reqs, messages, etc\), so that if you get a uisi you plug the megolm session into jaeger and see it client->server->server->client
and so see in a single trace why the target client doesn’t have that session.

eg “my client didn’t send keys because…”

it didn’t think the target device was in the room because X
it didn’t think the target user was in the room before X
it didn’t have a working Olm session to the target because X
the server dropped the message
the client didn’t retry

- \[ \] #32
- \[ \] Phone home \(lab option\)

The issue names no files, tests, or code entry points; begin by reviewing issue #32 and the “Phone home (lab option)” item. Define the Jaeger structured-activity trace across client and server hops, including the listed key and delivery failure reasons, and document how a Megolm session identifies a single trace.

Written by the indexing model from the issue text.