List media quarantine changes admin API is incomplete

https://github.com/element-hq/synapse/pull/19558 introduces a new admin API to list when media becomes (un)quarantined, including backfilling the table with historical data. But, currently, it only tracks quarantine changes made from the Admin API and doesn't flag a quarantine change in all the places where Synapse might automatically quarantine media.

The other sites, namely around URL previews and local uploads, appear to be related to the quarantine-by-hash functionality added last year. Media flagged as quarantine upon upload like this will *not* appear in the changes table (and thus not be exposed via the API either).

The means the `quarantined_media_changes` database table remains a best-effort source of truth.

For Trust & Safety's (T&S) intended use case this is fine behaviour because our hash matching is better than the sha256 matching that Synapse uses, but other use cases might be surprised by this. The intention is that any media which transitions from `unset` to `quarantined` or from `quarantined` to `unquarantined (aka unset)` is included in the table, even if the actor was "system". New media which isn't immediately quarantined *should not* have a starting record in the changes table.

https://github.com/element-hq/synapse/pull/19558 descoped this due to the amount of code/changes required to support it.

### Dev notes

- https://github.com/element-hq/synapse/pull/19558#discussion_r3028627669
- https://github.com/element-hq/synapse/pull/19558#discussion_r3017354260
- https://github.com/element-hq/synapse/pull/19558#discussion_r3028991956

Start by reading PR #19558 and its linked discussion notes to understand the existing admin API and quarantined_media_changes table. Trace the URL-preview, local-upload, and quarantine-by-hash paths mentioned in the issue; done means every unset-to-quarantined and quarantined-to-unset transition is recorded, while ordinary new media is not.

Written by the indexing model from the issue text.