[BE] Add an archived field to Tag, Taxonomy, and ObjectTag, and a deletion_locked field to ObjectTag #776

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 archived goes on all three but deletion_locked goes on only one. Any of the three record types can be retired, so all three need somewhere to record that. But only a tag association is ever depended upon directly: competency mastery is earned through the association between a competency and a piece of content, and that association is the thing whose removal would orphan a learner's status. A tag or a taxonomy matters only because associations exist beneath it, so their answer to "is anything depending on this" is derived from those associations rather than stored separately. #777 provides that derivation.

Why deriving beats storing for the upper two. A stored flag on a tag would have to be kept correct as associations come and go beneath it, which means either clearing it when the last association is unlocked, and getting that wrong loses learner history, or never clearing it, and then it only ever accumulates and stops meaning anything. One association carrying the fact, and the levels above reading down to it, has no such bookkeeping.

Why a stored flag on the association rather than a lookup at delete time. openedx_tagging must not know that competency-based education exists, and must not query another app's tables to decide whether a delete is safe. Storing the answer on the association row lets the owning feature push it in, and makes "is this in use" answerable inside the tagging app alone. The pushing side is #777 and #782.

No timestamp companions. Neither field gets an archived_at or locked_at. Nothing in the approved approach reads one, and a column no query uses is not free on tables this size.

Implementation specifics

• archived = models.BooleanField(default=False) on Taxonomy, Tag, and ObjectTag in src/openedx_tagging/models/base.py.
• deletion_locked = models.BooleanField(default=False) on ObjectTag only. Do not add it to Tag or Taxonomy; their in-use answer is derived in [BE] Add deletion-lock functions to openedx_tagging #777.
• Mirror the field definition [BE] Add archived field to Competency Criteria & Group models #716 introduces for CompetencyCriteriaGroup and CompetencyCriterion, so both sides of the feature look the same to a reader. Match its help_text wording and its db_index choice.
• Index for the queries that will actually run. [BE] Exclude archived tagging records from read paths and block edits to them #778 filters every tag and association read path on archived, and [BE] Branch tag and taxonomy deletes between archiving and hard delete #780 answers "is any association beneath this tag or taxonomy locked", so an index on Tag.archived, on ObjectTag.archived, and on ObjectTag.deletion_locked, or a composite covering the derivation query, is likely warranted, and Taxonomy.archived likely is not given how few taxonomy rows exist. Confirm against the queries [BE] Exclude archived tagging records from read paths and block edits to them #778 and [BE] Branch tag and taxonomy deletes between archiving and hard delete #780 add rather than indexing everything by default.
• One additive schema migration, no data migration. Both fields default to False, so existing rows need no backfill.
• PII: both fields are non-PII. These three models already carry their annotations, so confirm with make pii_check that adding these fields does not change the outcome rather than adding new annotations.
• Do not change any read or write path here. Adding a filter or a delete branch would collide with [BE] Exclude archived tagging records from read paths and block edits to them #778 through [BE] Fan out the content-tag-changed event when a taxonomy is archived #781. The fields must be inert on merge.
• Tests in the existing openedx_tagging model tests: all three models default archived to False; ObjectTag defaults deletion_locked to False; the two fields on ObjectTag can be set independently; the migration applies cleanly against a database holding existing taxonomies, tags, and associations and leaves them unarchived and unlocked.
• Out of scope: the lock API and the derived in-use query ([BE] Add deletion-lock functions to openedx_tagging #777), read and write inertness ([BE] Exclude archived tagging records from read paths and block edits to them #778), every delete branch ([BE] Branch tag association deletes between archiving and hard delete #779, [BE] Branch tag and taxonomy deletes between archiving and hard delete #780), the archive event fan-out ([BE] Fan out the content-tag-changed event when a taxonomy is archived #781), and any REST exposure of either field.

Files to modify

Context

• The approved implementation approach for competency delete and edit guardrails, on [Arch] Implementation approach for competency data delete/edit guardrails #655: the archive-versus-delete rule and why the lock is pushed in rather than looked up. Specifically the exchange starting at this comment and continuing through the deletion_locked-only-on-ObjectTag resolution.
• [BE] Add archived field to Competency Criteria & Group models #716 adds the equivalent archived field to CompetencyCriteriaGroup and CompetencyCriterion; match its shape.
• docs/openedx_learning/decisions/0003-competency-criteria-versioning.rst, Decision 3, for the rule that a tag association becomes archive-only once a learner status references it.
• Consumed by [BE] Add deletion-lock functions to openedx_tagging #777, [BE] Exclude archived tagging records from read paths and block edits to them #778, [BE] Branch tag association deletes between archiving and hard delete #779, [BE] Branch tag and taxonomy deletes between archiving and hard delete #780, and [BE] Fan out the content-tag-changed event when a taxonomy is archived #781.