Add mx_extract_media_events()

[TroyHernandez]

The extractor family covers text (mx_extract_text_events) and reactions (mx_extract_reactions) but not media, so a consumer that wants an image has to re-walk the raw sync and duplicate the msgtype filtering — which is exactly why chat.api's Matrix adapter reports attachments = FALSE today.

mx_extract_media_events(sync_resp, self_id) walks joined-room timelines for m.image/m.file/m.audio/m.video message events and returns normalized records in the family's shape (room_id, event_id, sender, is_self, ts, mentions, relates_to), plus the media fields:

• url fills from content$url (cleartext) or content$file$url (encrypted), so a consumer that only wants the address reads one field.
• sha256 surfaces from the encrypted file object; cleartext media carries no hash, so NULL there means unverified rather than fabricated.
• file rides verbatim (the relates_to treatment): decryption is the caller's business, and a partial view of key material helps no one.
• filename (MSC2530) is carried, with body documented as filename-or-caption.
• An event with no address in either place is skipped: nothing fetchable, nothing to report. m.sticker is a different event type and out of scope.

216 tests pass, including cleartext/encrypted extraction, is_self tagging, the no-address skip, and empty/malformed syncs. Downstream: chat.api's Matrix adapter can now map these onto its new chat_attachment records and flip attachments to installed-version-gated, the reaction_events pattern.