perf: Speed up media_names_for_ankihub_deck

[abdnh]

Related issues

This came up after my investigation of this community report: https://community.ankihub.net/t/i-accidently-deleted-the-anking-media-folder-from-my-laptop/605714

Proposed changes

This implements some small performance improvements for media sync:

• Replace _media_referenced_by_notes (which extracts media references from the live Anki collection) with a call to ankihub_db.media_names_for_ankihub_deck().
• Refactor media_names_for_ankihub_deck to avoid holding all note rows in memory.

How to reproduce

Media sync should work normally. This is mostly a performance improvement (but see note below).

Further comments

• Locally deleted notes now count and their media gets downloaded. I think this is acceptable considering that the sync process restores deleted notes if they get updates.
• This is unlikely to be the cause of the community report (it's most likely an IO issue because removing the .exists() check apparently unblocked the sync).

[RisingOrange]

The db.py refactor is a good change on its own and the tests are stronger for dropping the mocks. But swapping the data source in media_sync.py reintroduces INTP-338, so I'd split this PR: land the db.py work and drop the media_sync.py change.

_media_referenced_by_notes was added by #1230 for that ticket. Protected fields (and tag-based protection) only exist locally, so any user who protects a media-heavy field gets its media downloaded into an empty field again — not just the batch-edit repro in the ticket. Passing the protected-fields config in doesn't rescue it, since a field protected after it was populated still holds content that does need downloading. Same root cause as the locally-deleted-notes case you mention: media need is a property of the user's state, not AnkiHub's. Server-side filtering can't distinguish those cases either.

None of which the code says anywhere, which is what made that function look safe to swap out — so it's worth adding a comment on it recording why it reads the collection rather than ankihub_db.

The db.py half is worth landing on its own though: on a synthetic 20k-note, 10-field collection (~157 MB of field text), media_names_for_ankihub_deck goes from 0.714s / 193 MB peak to 0.657s / 0.7 MB, and menu.py:508 gets that on the upload path for free.

And for what it's worth, keeping the collection scan costs almost nothing: on that same collection the existing col.get_note() loop measures 0.674s / 0.7 MB, against 0.657s for the ankihub_db version.

[abdnh]

Thanks. I reverted the change and added a comment.

Originally I made the change because I suspected a deadlock issue caused by non-serialized collection access, but I couldn't confirm that.