[BE] Return taxonomy type on the per-object tag endpoint

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

What this ticket does and does not decide. The rule for deciding whether a taxonomy is a competency taxonomy is #618's call to make, not this ticket's, and this ticket does not redecide it, reimplement it, or move it. Once #618 lands, this ticket follows its hasattr(taxonomy, "competencytaxonomy") check, applied to one more openedx-platform serializer, the one that returns a content object's tags.

Why the per-object endpoint is the one that matters. The Course Outline page and the Libraries page do not fetch the full taxonomy list to render a unit's tags. They fetch the tags applied to that object, and each tag arrives with its taxonomy identified but not typed. Without the type on that payload, the frontend would have to make a second request per taxonomy to decide whether to show a delete control, which is why #784 cannot be built until this lands.

Both pages read the same endpoint, confirmed against the frontend code. Course Outline's tag display and the Libraries pages' tag display both go through the same shared content-tags-drawer module in frontend-app-authoring: the same useContentTaxonomyTagsData() hook, calling the same api/content_tagging/v1/object_tags/{contentId}/ endpoint. There is one serializer to change, not two.

The performance shape to watch. A content object can carry tags from several taxonomies, and a Course Outline request covers many objects at once. Computing the type per tag by fetching its taxonomy would be an N+1 on one of the more heavily used authoring reads. The taxonomies involved must be fetched once for the whole response.

This is a purely additive change. The field is added; nothing existing is removed or renamed, so clients that do not know about it are unaffected.

Implementation specifics

• Confirm #618 has landed before starting. TaxonomyOrgSerializer.get_taxonomy_type() doesn't exist yet as of this writing; this ticket has nothing to reuse until it does.
• Once #618 lands, reuse its exact computation rather than duplicating the rule. TaxonomyOrgSerializer.get_taxonomy_type() (openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py) is planned to return "competency" if hasattr(obj, "competencytaxonomy"), "tags" otherwise. Call the same check, or extract it to a shared helper both serializers call, and say in the PR description which you did.
• Add the field to ObjectTagOrgByTaxonomySerializer, in that same openedx-platform file, alongside TaxonomyOrgSerializer. This backs ObjectTagOrgView (views.py, same directory), which serves (api/content_tagging/v1/object_tags/{contentId}/, confirmed the single endpoint both Course Outline and Libraries read). Expose the field on each tag in the response, alongside the taxonomy identity already present.
• Do not add anything to openedx_tagging's own ObjectTagsByTaxonomySerializer/ObjectTagView in openedx-core. ObjectTagOrgByTaxonomySerializer already subclasses it; this ticket only adds to the subclass, the same relationship #618 establishes for the taxonomy endpoints.
• Avoid the N+1. Use select_related on the tag's taxonomy (and its competencytaxonomy relation, mirroring #618's planned TaxonomyOrgView.get_queryset() change) in ObjectTagOrgView's queryset so the taxonomies come back with the tags, and assert it with a query-count test rather than trusting inspection.
• Do not change any other field, and do not change the endpoint's shape. Additive only.
• Tests: a competency tag reports the competency type; an ordinary tag does not; an object carrying both is distinguishable; an untagged object succeeds; a query-count assertion over an object carrying tags from several taxonomies; a regression assertion that the previously existing fields are unchanged.
• Out of scope: the frontend consumption (#784), any change to the taxonomy endpoints (#618’s own scope), and any change to how taxonomy type is decided.

Files to modify

Context

• ADR 0013 (docs/openedx_tagging/decisions/0013-competency-taxonomy-detection.rst), for the rule this follows and why it must not move into openedx_tagging.
• #618, for the identical pattern planned for the taxonomy endpoints (TaxonomyOrgSerializer/TaxonomyOrgView): entirely in openedx-platform, nothing added to openedx_tagging or the CBE app. Still in development as of this writing; checked directly against the live code, not assumed.
• The approved implementation approach on #655, for why the frontend needs to distinguish competency tags.
• frontend-app-authoring's content-tags-drawer/data/api.ts and apiHooks.ts, for the shared hook and endpoint both Course Outline and Libraries read.
• Consumed by #784. Depends on #618.