Add tag catalog deprecation and semantic immutability

## Parent

#792

## What to build

Complete catalog lifecycle behavior across every delivered tag mode. Catalog managers can deprecate and reactivate tag definitions and controlled values; authors continue to see and filter existing deprecated assignments but cannot add them to a new target or introduce a newly deprecated value. Studio explains immutable semantic fields and guides managers to create a replacement identity rather than repurposing an established definition. Carry lifecycle through catalog APIs, assignment validation, list/filter projections, Studio management/editor surfaces, audit/events, and provider tests.

Covers parent user stories 12–14 and 52–58.

## Acceptance criteria

- [ ] Tag definitions and controlled values expose `Active` and `Deprecated` lifecycle states with authorized deprecate/reactivate commands.
- [ ] Existing deprecated assignments remain readable, filterable, grouped, auditable, and renderable in Studio.
- [ ] An idempotent replacement may retain an existing deprecated assignment, while assigning that deprecated definition/value to a new target or introducing it as a new value is rejected.
- [ ] Studio distinguishes deprecated catalog entries and existing assignments and prevents unsupported new selection without silently removing data.
- [ ] Canonical key, value mode, and cardinality cannot be mutated after their accepted immutability boundary; removing assignments does not reset that boundary.
- [ ] Display name, description, color, and controlled-value sort order remain safely editable and do not rewrite assignments or saved stable identities.
- [ ] A semantic change requires creation of a new definition/value identity; Studio explains the replacement path and does not present a destructive rename as equivalent.
- [ ] Version 1 exposes no hard-delete command for tag definitions or controlled values.
- [ ] Catalog lifecycle and presentation changes produce the correct audit facts/events without masquerading as target assignment changes.
- [ ] Tenant isolation, optimistic concurrency, and provider-independent uniqueness remain enforced during deprecate/reactivate races.
- [ ] API acceptance, Studio browser, and Groundwork provider-conformance tests cover lifecycle across marker, controlled, free-text, single, and multiple modes.

## Blocked by

- #801
- #800
- #802

Start with parent issue #792 and blockers #801, #800, and #802, then trace the catalog APIs, assignment validation, Studio management/editor surfaces, audit/events, and provider tests. Use the API acceptance, Studio browser, and Groundwork provider-conformance tests as entry points. Done means lifecycle, immutability, isolation, concurrency, audit behavior, and all listed tag modes are covered without destructive data changes.

Written by the indexing model from the issue text.