Add classification review and safeguard explanation to authoring and catalog UX

Tracked by #590. Depends on #592 and #593. Coordinate with editor epic #399 and structured diagnostics #396.

## Outcome

Authors, reviewers, operators, and catalog consumers can inspect field concepts, classifications, provenance, review state, and effective safeguard requirements without reading raw YAML or exposing source values.

## Requirements

- Provide a field-oriented review view showing:
- dataset, entity, and field name;
- physical type;
- primary and additional semantic concepts;
- classification facet and term;
- vocabulary/profile identity and version;
- declared, derived, or proposed provenance;
- review state;
- effective safeguard requirements and enforcement status.
- Support filtering by concept, classification, vocabulary/profile, review state, and enforcement status.
- Keep labels human-readable while retaining immutable IRIs and stable rule IDs underneath.
- Explain why a classification or control applies and which reviewed artifact supplied it.
- Use the exact compiled metadata and explanation contracts rather than reimplementing semantic or policy logic in a UI.
- Integrate authoring diagnostics with #396 and later editor clients under #399.
- Keep unreviewed suggestions visually and structurally distinct from accepted classifications.
- Do not inspect live registry values or trigger scripts, connectors, or network vocabulary lookups as a side effect of browsing metadata.
- Respect existing catalog metadata authorization and avoid widening public schema discovery accidentally.

## Acceptance criteria

- [ ] A reviewer can inspect a table-like field inventory with typed classification badges and authoritative concept sources.
- [ ] Every displayed control links to a value-free explanation and stable rule ID.
- [ ] Unreviewed suggestions cannot be mistaken for released metadata or active policy.
- [ ] Filtering and search operate only over bounded compiled metadata.
- [ ] The UI renders PublicSchema, EU SEMIC, and local vocabulary bindings without privileging one hardcoded namespace.
- [ ] Authorization tests prove restricted metadata does not become public through the new view.
- [ ] A clean authoring journey is documented and tested separately from runtime enforcement.

## Non-goals

- A general data marketplace
- Source-data profiling or sampling
- Policy activation from a browser click without the governed config workflow
- Duplicating Registry compiler or PDP logic in frontend code
- Editor-specific language-server implementation already tracked by #399

Start by reading the tracked and dependent issues #590, #592, #593, #396, and #399, then locate the existing compiled metadata and explanation contracts. The work is done when the field-oriented review view, bounded filtering, value-free explanations, authorization coverage, and separately documented authoring journey satisfy the listed acceptance criteria.

Written by the indexing model from the issue text.