[BE] Fan out the content-tag-changed event when a taxonomy is archived

This section is background and a suggested approach, not the ticket's source of truth. The User Story and Acceptance Criteria define what must be true when the work is done.

In short

Why archiving needs an event when deleting already has one. A hard delete removes rows via a QuerySet.delete(), which still fires pre_delete per row and reaches the existing signal handler. An archive is a bulk .update(), which Django does not fire any signal for at all. Without an explicit event, the index has no way to learn anything happened.

Fan out per content object, not per tag. The index is keyed by content object, and one object can carry several tags being archived in the same request, whether that's several tags under one archived taxonomy or several tags archived together in one bulk delete_tags() call. Emitting per tag would reindex the same object repeatedly for no benefit, so the set of affected object ids is collected and deduplicated first and one event is emitted for each.

Reuse the existing object-ids task for both triggers. src/openedx_tagging/tasks.py already has emit_content_object_associations_changed_for_object_ids_task, used today by the hard-delete signal. Both the taxonomy branch and the tag branch collect their own affected object ids and hand them to this same task; neither needs a new event or a new task.

The event is emitted after the archive commits, not inside it. The archive is the thing that must succeed; notifying the index is a follow-up that Celery retries. Emitting inside the transaction would announce an archive that could still roll back, and a delivery failure must not undo the archive.

Finding the affected objects means reading archived rows. By the time this runs, #778 has made archived records invisible to the normal read paths, and #780's ancestor archiving may have archived several tags in the same request. Use the opt-out #778 documents — likely a keyword like include_archived=True on the relevant openedx_tagging.api read function, or a queryset method, though #778 hasn't pinned down the exact shape yet — so this ticket's queries see archived rows while ordinary callers keep the default filtered view.

A note on manually verifying this end-to-end. This repo has no UI of its own to check this in. Once openedx-platform and Meilisearch are both involved, the Libraries search/filter UI is a reasonable place to confirm a retired tag stops appearing, since it's a straightforward consumer of the same per-object tags data this event refreshes. That's a devstack-level check across repos, not part of this ticket's own automated tests.

Implementation specifics

• Taxonomy branch: trigger from the archive branch #780 adds to TaxonomyView.perform_destroy, registered with transaction.on_commit so it fires only once the archive has committed. Do not emit from inside the archive write.
• Tag branch: trigger from the archive branch #780 adds to Taxonomy.delete_tags(), registered with transaction.on_commit the same way, right after the .update(archived=True) call over the computed archive set.
• Collect the affected object ids per branch:
  • Taxonomy branch: the distinct object_id values of ObjectTag rows whose tag belongs to the archived taxonomy.
  • Tag branch: the distinct object_id values of ObjectTag rows whose tag is in the set of tag ids just archived by that one delete_tags() call.
• Both using the documented opt-out from #778 so archived rows are included. One query per branch, not a query per tag.Hand them to the existing task emit_content_object_associations_changed_for_object_ids_task in src/openedx_tagging/tasks.py, called the way src/openedx_tagging/signal_handlers.py already calls it for the hard-delete tag-change case. Do not define a new event or a second emission path.
• Deduplicate before emitting. The existing task emits once per distinct object id; make sure the id set handed to it is already distinct so the guarantee does not depend on the task.
• Batch a large fan-out. A framework-wide taxonomy, or a large with_subtags archive, can affect a great many objects, so chunk the id list rather than passing an unbounded list in one task payload. Follow whatever batching the neighbouring tasks in that module already use, and if they use none, say so on the issue rather than inventing a batch size silently.
• Do not change the hard-delete path. It already notifies through the existing signal handling, and adding a second emission would double-reindex.
• Retry is Celery's job. The task already runs asynchronously; do not catch and swallow a delivery failure in either archive path, and do not make either archive conditional on it.
• Tests in the existing openedx_tagging task and signal tests: one event per affected object, for each branch; exactly one event for an object carrying several archived tags at once, for each branch; no event when nothing is tagged, for each branch; a query-count assertion showing the object ids are gathered in a constant number of queries; the archive survives a task failure, for each branch; the hard-delete path emits exactly what it emits today and no more, for both a tag and a taxonomy.
• Out of scope: the archive branches themselves (#780), read-path exclusion (#778), the ObjectTag-level archive branch (#779, already covered by openedx-platform's existing tag_object() wrapper, confirmed while reviewing this ticket), and anything in the search index implementation, which lives outside this repository.

Files to modify

Context

• The approved implementation approach on #655, for why an archived taxonomy or tag must not keep being served by the index.
• src/openedx_tagging/tasks.py for emit_content_object_associations_changed_for_object_ids_task and the CONTENT_OBJECT_ASSOCIATIONS_CHANGED event it sends.
• src/openedx_tagging/signal_handlers.py for how the existing hard-delete case calls that task, and why a bulk update() doesn’t reach it.
• openedx-platform's openedx/core/djangoapps/content/search/handlers.py and documents.py, for the confirmed-unaffected consumer side: it rebuilds a content object's tags from get_object_tags() on receiving this event, so it needs no changes once #778 lands.
• openedx-platform's openedx/core/djangoapps/content_tagging/api.py, tag_object(), for the confirmed-unaffected ObjectTag-level wrapper that already emits this event unconditionally, covering #779. Between this and the point above, no other repo-side gap was found once this ships — the only missing piece was the trigger for the two archive branches this ticket adds.
• Depends on #780 for both archive branches it hooks into and #778 for the opt-out that lets it read archived rows. Sequence alongside #780 so no released version archives a taxonomy or a tag without notifying the index.