[FE] Add taxonomy type badge to Taxonomies page

[mgwozdz-unicon]

Use Case

As a Platform Administrator, I need to see a taxonomy type badge on each taxonomy card on the Taxonomies page so that I can quickly distinguish Competency Taxonomies, standard tag taxonomies, and system-level taxonomies at a glance without leaving the page.

---

Description

Today, the Taxonomies page in Studio displays a "System-level" badge only on system-defined taxonomies. All other taxonomies show no type indicator.

This issue updates every taxonomy card to always display exactly one type badge:

• "Competency" — new badge for Competency Taxonomies, visually distinct color from System-level
• "Tags" — new badge for standard tag taxonomies
• "System-level" — existing badge, retained as-is for system-defined taxonomies

The badge is determined by two fields already present (or being added) to the API response: systemDefined (existing boolean) and taxonomyType (added by #618). The priority order is:

1. If systemDefined is true → show "System-level" badge (unchanged behavior)
2. Else if taxonomyType is "competency" → show "Competency" badge
3. Otherwise → show "Tags" badge

This ticket is the display counterpart to the import dropdown added in #615 and removes the need for Postman verification of taxonomy type after import.

Dependency: Requires #618 (GET endpoint returning taxonomy_type) and #630 (verifies TaxonomyOrgSerializer in edx-platform passes taxonomy_type through in the /api/content_tagging/v1/taxonomies/ response) to be merged first.

---

Acceptance Criteria

Scenario 1: Competency taxonomy shows Competency badge

Given a Competency Taxonomy exists on the platform
When I navigate to the Taxonomies page
Then the taxonomy card displays a "Competency" badge
And the badge is visually distinct in color from the System-level badge

Scenario 2: Standard tag taxonomy shows Tags badge

Given a standard tag taxonomy exists on the platform
When I navigate to the Taxonomies page
Then the taxonomy card displays a "Tags" badge

Scenario 3: System taxonomy shows System-level badge

Given a system-level taxonomy exists on the platform
When I navigate to the Taxonomies page
Then the taxonomy card displays a "System-level" badge

Scenario 4: Every taxonomy card shows exactly one type badge

Given multiple taxonomies of different types exist on the platform
When I navigate to the Taxonomies page
Then each taxonomy card displays exactly one type badge
And no taxonomy card displays more than one type badge

---

Technical Notes

Files to Create

File	Purpose
src/taxonomy/taxonomy-card/TaxonomyTypeBadge.jsx	New badge component that accepts systemDefined and taxonomyType props and renders the correct label and color

Modified Files

File	Nature of modification
src/taxonomy/data/types.ts	Add `taxonomyType: 'competency'
src/taxonomy/taxonomy-card/index.jsx	Replace conditional SystemDefinedBadge rendering (lines 122–128) with TaxonomyTypeBadge, passing both systemDefined and taxonomyType

Implementation Notes

• taxonomyType is not yet in the frontend data layer. Add taxonomyType: 'competency' | 'tags' to the TaxonomyData interface in types.ts (lines 2–18). The camelCaseObject() call in the API hook automatically converts taxonomy_type from the response to taxonomyType — no hook changes needed.
• Badge priority logic belongs in TaxonomyTypeBadge. The component receives both systemDefined: boolean and taxonomyType: 'competency' | 'tags' and applies the priority order: System-level first, then Competency, then Tags. Keeping the logic inside the component makes it testable in isolation.
• Visual reference for the new component: Use the same badge/pill UI component already used by src/taxonomy/system-defined-badge/index.jsx as the pattern. "System-level" retains its existing styling; "Competency" uses a distinct color variant; "Tags" uses a neutral color variant.
• Card update: TaxonomyCard (taxonomy-card/index.jsx, lines 122–128) currently conditionally renders <SystemDefinedBadge /> when showSystemBadge is true. Replace this with <TaxonomyTypeBadge systemDefined={systemDefined} taxonomyType={taxonomyType} /> — always rendered, no conditional, since every taxonomy now shows a badge.
• systemDefined is not removed. It remains on the interface and in existing code. This ticket does not clean it up; that is a separate concern.
• taxonomy_type passthrough in edx-platform: The frontend calls /api/content_tagging/v1/taxonomies/. Verify that TaxonomyOrgSerializer (edx-platform/openedx/core/djangoapps/content_tagging/rest_api/v1/serializers.py, lines 70–99) includes taxonomy_type in its response — this is covered by [BE][edx-platform] Verify Taxonomy Type passes through TaxonomyOrgSerializer #630, but confirm it is merged and working before testing this ticket.

Example Resolution Prompt

In frontend-app-authoring, add taxonomy type badges to the Taxonomies page. In src/taxonomy/data/types.ts, add taxonomyType: 'competency' | 'tags' to the TaxonomyData interface. Create src/taxonomy/taxonomy-card/TaxonomyTypeBadge.jsx that accepts systemDefined: boolean and taxonomyType: 'competency' | 'tags' props and renders exactly one badge: "System-level" if systemDefined is true, "Competency" if taxonomyType === 'competency', or "Tags" otherwise. Use the same badge/pill UI component as src/taxonomy/system-defined-badge/index.jsx as the visual pattern, with a distinct color variant for "Competency" and a neutral variant for "Tags". In src/taxonomy/taxonomy-card/index.jsx, replace the conditional <SystemDefinedBadge /> at lines 122–128 with <TaxonomyTypeBadge systemDefined={systemDefined} taxonomyType={taxonomyType} /> — always rendered, no conditional. Do not remove systemDefined from the interface or any existing code.

[jesperhodge]

The dependencies in the ticket mention:
"[it is required] that TaxonomyOrgSerializer in edx-platform passes taxonomy_type through in the /api/content_tagging/v1/taxonomies/ response."
What ticket does that get implemented in? We should link that ticket. If none, we should create a backend ticket for it.

[jesperhodge]

Claude-supported feedback:

• Type 'competency' | null is a leaky abstraction. The component renders "Tags" for null, which means the component is encoding the business rule that "null means Tags." A cleaner API contract: the GET endpoint returns "tags" for standard taxonomies and "competency" for competency taxonomies. Then the type is 'competency' | 'tags' and the badge component doesn't need to translate null → "Tags". This inconsistency (Create accepts "tags", GET returns null) is a design smell that will confuse future consumers.
  Since that concerns the API schema, I'll add this comment to [BE] Update Get endpoint to return Taxonomy Type. #618 as well.

[illiphilli]

Updated view of Taxonomy Cards with Paragon Badges (info for competencies, light for tags) indicating their type.

Figma Link

[mgwozdz-unicon]

@jesperhodge Addressing both points above, updated the ticket description to match:

On the TaxonomyOrgSerializer passthrough ticket: that work is tracked in #630, the edx-platform companion ticket split off from #618. Linked it in the Dependency line alongside #618. Also resolved the ticket's other placeholder links while I was in there: the taxonomyType field dependency now points to #618, and the cross-reference to the import dropdown now points to #615.

On the 'competency' | null leaky abstraction: agreed, and it's the same fix already applied on #618 and #615. taxonomyType is now typed 'competency' | 'tags' throughout — the TaxonomyData interface, the TaxonomyTypeBadge component's props, and the Example Resolution Prompt — so the component no longer needs to treat null as an implicit "Tags."

Full updated ticket description reflects both changes.