Add normalized free-text tags and bounded suggestions

## Parent

#792

## What to build

Extend the tagging tracer bullet with single-valued free-text tag definitions. Workflow authors can enter a value directly or choose a bounded existing-value suggestion; Elsa Server preserves display text, compares an application-produced normalized exact key, and supports exact filtering without substring/fuzzy semantics. Carry the behavior end to end through catalog management, assignment, workflow-definition list queries, Studio input and suggestions, audit/events, and Groundwork provider conformance.

Covers parent user stories 3, 6–7, 11, 31, 36, 50, and 75–76.

## Acceptance criteria

- [ ] A free-text tag definition declares `FreeText` plus `Single` semantics and uses the finalized maximum display length and normalization contract from the parent PRD.
- [ ] The application trims surrounding whitespace, applies the specified Unicode normalization and case-insensitive comparison transformation, persists the normalized key, and preserves a readable display value.
- [ ] Equivalent normalized values compare and filter as one semantic value across every supported provider.
- [ ] Studio exposes a free-text editor that accepts a new value while offering bounded existing-value suggestions.
- [ ] Suggestion requests are tenant-scoped, prefix-bounded, deterministically ordered, paged/limited, and never enumerate an unbounded distinct-value set.
- [ ] The workflow-definition query supports normalized exact `AnyOf` and `NoneOf` semantics for free-text values; substring, fuzzy, and full-text matching are rejected or absent.
- [ ] Workflow-definition rows render the preserved free-text display value without using it as durable identity.
- [ ] Cross-tenant values and suggestions cannot leak through results, counts, errors, audit data, or events.
- [ ] Audit facts and post-commit events carry the semantic normalized value plus safe display information needed by consumers.
- [ ] API acceptance, Studio browser, normalization matrix, and provider-conformance tests extend the shared seams and prove equivalent comparison plus bounded suggestion work on every supported provider.

## Blocked by

- #797

Start by reading parent issue #792 and the blocking issue #797, then map the required behavior across catalog management, assignment, workflow-definition queries, Studio, audit/events, and Groundwork provider conformance. Use the listed API acceptance, Studio browser, normalization matrix, and provider-conformance tests as the validation seams; done means all acceptance criteria pass without cross-tenant leakage or unbounded suggestions.

Written by the indexing model from the issue text.