feat: bulk admin actions for Media.skip

[Agi-Asi]

Problem

Managing a large library through the Django admin requires editing every media item individually to toggle Skip or Can download — the exact pain point in #493, where bulk-editing those two flags was requested ("A real time saver would be to expose actions such as enabling/disabling Skip or Can download").

Change

Adds the standard Django admin bulk actions to MediaAdmin, scoped to exactly the two fields requested:

• Set / unset "skip" — also sets manual_skip to match, so a bulk un-skip isn't immediately re-skipped by the filtering logic, and a bulk skip is recorded as the operator's explicit decision.
• Set / unset "can download".

Also adds list_filter for can_download / skip / downloaded, so the rows to bulk-edit can be narrowed down first (without a filter the actions are much less useful on big libraries).

Implementation uses queryset.update(), so a bulk action across thousands of rows is a single UPDATE statement rather than thousands of model saves.

Testing

• New sync/tests/test_admin.py covers both action pairs end-to-end against real model rows (including the manual_skip coupling) plus action registration.
• Full Django suite: manage.py test — 54 tests, OK.
• The CI ruff gate passes.

Fixes #493

[meeb]

This seems fine with to me. @tcely is toggling flags sufficient to eventually trigger the required worker events?

[tcely]

Is toggling flags sufficient to eventually trigger the required worker events?

I don't understand the question.

[meeb]

As in, is just setting can_download to True sufficient to trigger a task at a later date, or does this need to have .save() called on each object as well to re-evaluate the state of the media item.

[tcely]

The media_post_save signal is the only place the can_download attribute is recalculated.

That is eventually triggered for every Media instance per source: A) after editing a source or B) after indexing a source.

Is this sufficient, or do you believe a save_media task needs to be added to the tasks queue?

[Agi-Asi]

Good question re: signals — since queryset.update() deliberately bypasses save()/media_post_save, the flags flip immediately but re-evaluation waits for the next source edit/index pass, as @tcely described. That felt acceptable for an admin bulk tool (it mirrors what the DB-level toggle means), but if you'd prefer eager re-evaluation I'm happy to switch the actions to iterate queryset and call save() per object (or enqueue a save_media task per item) — just tell me which shape you want.

[meeb]

I'm fine with it waiting for an Indexing to trigger any events, just checking.

[tcely]

Please implement a save_media task per changed item and add a setting that enables queuing those tasks. By default, the tasks should not be queued.

[Agi-Asi]

Done in be4313b — implemented exactly as requested:

• New setting SAVE_MEDIA_AFTER_BULK_ACTION (container env: TUBESYNC_SAVE_MEDIA_AFTER_BULK_ACTION), default False so nothing is queued unless explicitly enabled.
• When enabled, each bulk action queues a save_media task per changed item (via save_media.map() over the queryset UUIDs), so flags are re-evaluated without waiting for the next source edit/index pass.
• Documented in the README env-var table and local_settings.py.container.
• Two new tests: default = save_media.map not called; enabled via override_settings = called once with exactly the changed UUIDs. All 5 admin tests pass locally, ruff gate clean.