Add classification review and safeguard explanation to authoring and catalog UX

[jeremi]

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 Expose versioned editor metadata and structured project diagnostics #396 and later editor clients under Epic: First-class editor support for Registry Stack project authoring #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 Epic: First-class editor support for Registry Stack project authoring #399