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

[barodeur]

#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, clarified in Matrix v1.14 by matrix-spec#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 Drop federation device list updates from non-compliant user IDs #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.