[BE] Branch tag association deletes between archiving and hard delete

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

Where the branch goes, and why there is no DELETE endpoint to use. Tag associations are not removed one at a time. A caller sends the complete list of tags an object should now have, and tag_object() reconciles: it keeps what is still listed, adds what is new, and removes what is missing. The removal step inside that reconciliation is the only place an association is ever deleted, so it is the only place the branch can go.

What the branch decides. For each association that reconciliation would remove, if it is locked against deletion it is archived instead, and if it is not, it is deleted exactly as today. The rule is deliberately narrow: without a lock, nothing about today's behavior changes.

Why re-applying un-archives in place rather than creating a new row. An archived association still occupies its slot in the unique constraint on the object, taxonomy, and tag together. Creating a second row for the same three values would either violate that constraint or force it to be widened to include the archived flag, and widening it would let duplicate live associations exist. Un-archiving the existing row also keeps any competency criterion's foreign key pointing at a stable row rather than orphaning it against a superseded one.

• This is a distinct question from, and unaffected by, #655's later "error rather than auto-unarchive" resolution about recreating a Tag with the same value as an archived one: that discussion concerns whether creating a new Tag row should silently resurrect an old one when the two might represent different competencies with a coincidentally shared name, an ambiguity that does not exist here, where the same Tag id is being reapplied to the same object id, not recreated.

A consequence worth stating plainly. Because the original row comes back, its mastery history comes back with it. An author who removes a competency tag and later re-adds it does not get a clean slate; the learners previously evaluated against that association are still evaluated against it. That is the intended behavior, and it is the reason the confirmation dialog in #775 says the action cannot be undone from this screen rather than promising deletion.

Implementation specifics

• The branch goes in tag_object() in src/openedx_tagging/api.py, in the step that removes associations no longer present in the submitted tag list. Do not add a new public function and do not add a DELETE endpoint.
• Read the lock through the query function #777 adds, not by reading deletion_locked directly, so the two delete branches in this ticket and #780 ask the same question the same way.
• Resolve the removal set in bulk, then split it in two. One .update(archived=True) over the locked ids and one delete over the rest, rather than a per-association branch inside a loop. tag_object() already handles a whole object's tags at once, and a per-row query here would be an N+1 on every content-tagging save.
• The un-archive step needs to see archived rows, which #778 filters out of the normal read paths. Use the documented opt-out that #778 provides rather than adding a second one.
• Un-archive in place with .update(archived=False) on the existing row. Do not delete and recreate, and do not touch the unique constraint on (object_id, taxonomy, tag).
• Leave the lock alone when un-archiving. A re-applied association is still depended upon by the same learner statuses, so clearing deletion_locked would make the next removal destroy them.
• The response shape does not change. A caller must not be able to tell archiving from deletion, per the approved approach, so do not add a field reporting which happened.
• Check the interaction with resync_object_tags and copy_tags in the same module. Both create or move associations and neither should resurrect an archived row unintentionally or copy the archived flag to a new object. State what each does in the PR description even if neither needs changing.
• Tests in the existing openedx_tagging API tests, one per scenario, plus: a query-count assertion showing the branch adds a constant number of queries rather than one per association; a test that the unique constraint is unchanged; a test that a competency criterion's foreign key still points at the same row after a remove-then-re-apply cycle.
• Out of scope: setting the lock (#782), tag and taxonomy deletes (#780), the archive event fan-out (#781), and the confirmation dialog (#786).

Files to modify

Context

• The approved implementation approach on #655: archive only when a learner status row exists, un-archive in place on re-apply, and why the caller is not told which happened.
• src/openedx_tagging/api.py, tag_object(), for the existing reconciliation this branch sits inside, and resync_object_tags and copy_tags for the neighbouring paths.
• src/openedx_tagging/models/base.py for the unique constraint on ObjectTag.
• Depends on #776 for both fields, #777 for the lock query, and #778 for the documented opt-out that lets this path see archived rows. The lock itself is set by #782.