Non-compliant user IDs are still forwarded to clients outside event context

element-hq/synapse#20115 drops inbound `m.device_list_update` EDUs from non-compliant (grandfathered historical) user IDs, implementing the example given by the Matrix v1.14 clarification:

> For current room versions, servers must still accept events using such user IDs over federation; however they SHOULD NOT forward such user IDs to clients when referenced outside the context of an event. For example, device list updates from non-compliant user IDs would be dropped by the receiving server.
>
> — [Matrix spec](https://spec.matrix.org/v1.14/appendices/#historical-user-ids), clarified in Matrix v1.14 by [matrix-spec#1506](https://github.com/matrix-org/matrix-spec/issues/1506)

Device list updates are only the spec's example. Other EDU types also surface non-compliant user IDs to clients outside event context, with no localpart check today:

- `m.signing_key_update` — feeds the same `/sync` `device_lists.changed` field, so it currently bypasses the #20115 fix
- `m.presence` — `/sync` `presence` section
- `m.typing` — `user_ids` in ephemeral typing notifications
- `m.receipt` — user ID keys in ephemeral read receipts
- `m.direct_to_device` — `sender` of to-device messages; filtering this one would hard-break E2EE with affected users

**Question:** should the same filtering be applied to some or all of these, or is the device list example the intended extent of the SHOULD NOT? Happy to implement whatever is decided — `m.signing_key_update` at least seems worth it, since it reopens the exact leak #20115 closes.

Start by reviewing the /sync device_lists.changed and presence sections, plus ephemeral typing, receipt, and to-device handling for the listed EDU types. First resolve which non-compliant user IDs the Matrix clarification requires filtering and whether m.direct_to_device is exempt; done means an agreed scope with tests covering each affected client-facing path.

Written by the indexing model from the issue text.