Implement ECCA registry catalog and capability discovery

[enricopiovesan]

Parent

Part of #894. Blocked until Spec 534 and its ADR are approved in #895.

Problem

The registry has event declarations but no ECCA-grade catalog entry, contract discovery surface, or evidence-backed capability relationships.

Definition of Done

• Ingest and validate the approved event-governance descriptor and JSON Schema with each registry publication.
• Reject event publication when required owner, purpose, lifecycle, classification, compatibility, or semantic fields are absent or invalid.
• Persist immutable contract versions, schema links, lifecycle/deprecation/replacement metadata, producer and declared-consumer relationships.
• Expose dedicated event contract pages and capability Publishes/Consumes sections with owner, lifecycle, exposure, field classifications, schema/version, and stable support route.
• Render declared relationships separately from observed runtime lineage and surface drift.
• Provide searchable/filterable event discovery by type, domain, owner, lifecycle, classification, producer, consumer, and payload-field metadata.
• Provide navigable producer-consumer lineage from both a capability and an event contract.
• Generate AsyncAPI as a derived discovery/export view without making it contract authority.
• Add fixtures and integration tests covering valid publication, each rejected metadata class, immutable evolution, lifecycle/deprecation, classification visibility, and declared/observed relationship rendering.

Validation

• Unit, integration, and catalog fixture tests pass.
• Accessibility and registry UI checks pass where applicable.
• Conformance fixtures prove the interface matches approved Spec 534 and ADR.

Non-goals

Runtime transport enforcement and the reference application, which are separate tickets.

[enricopiovesan]

Blocked pending approval of ECCA Spec 534 and its ADR in #895, as stated in this issue. Implementation must use the approved contract rather than the current Draft.

[enricopiovesan]

Blocked: approved Spec 534 assigns #896 to the registry catalog/discovery boundary, but this Traverse repository has no crates/traverse-registry implementation surface (the Cargo workspace contains no registry crate). The work requires the traverse-framework registry repository or an explicitly approved cross-repo delivery plan. No runtime-only substitute is being added here.

[enricopiovesan]

Registry-side unblock: traverse-registry 0.10.0 published

traverse-framework/registry's registry-side ECCA implementation is
published and ready to build against. Tracked in
traverse-framework/registry#150 (umbrella), governed by a new
specs/016-ecca-event-product-adoption (Draft, translating Spec 534/
ADR-0028 into this crate — pending the registry repo owner's standalone
spec-approval sign-off, but implemented and shipped per this repo's normal
Draft-spec-implementation precedent).

Published interface: traverse-registry 0.10.0 (crates.io, docs.rs).

• EventProductDescriptor + validate_event_product_descriptor — the ECCA
  descriptor and publish-time validation, composed additively around the
  existing traverse-contracts::EventContract (support route, per-field
  data classification, lifecycle/replacement pairing, past-tense semantic
  naming, immutable republication).
• EventProductRegistry — stores validated descriptors, indexes declared
  publisher/subscriber capability relationships, and
  catalog_search/discover for deterministic lookup by event, capability,
  domain, owner, lifecycle, and classification.
• ObservedLineageStore — a structurally separate store for
  runtime-observed lineage and drift evidence, isolated from declared
  descriptor state by construction (mirrors this repo's own
  specs/015-runtime-usage-telemetry-resolve-hook hook-isolation shape).
  No event payloads, roots, or credentials in evidence by type design.
• generate_async_api_document — AsyncAPI 2.6.0 as a pure derived export,
  never contract authority.

Validation commands:

cargo add traverse-registry@0.10.0
cd crates/traverse-registry && cargo test   # 335 tests, this repo's own suite

Conformance fixtures for #897/#898: crates/traverse-registry/fixtures/event-products/ —
a portable, language-agnostic JSON fixture set (MANIFEST.json + one
fixture per validation outcome: valid acceptance, one per rejection error
code, and an existing/candidate pair for immutable version evolution).
Test your own runtime/reference-app port against these same fixtures to
detect drift from the registry's validator without depending on this
crate's Rust internals.

Integration path: pin traverse-registry = "0.10.0" in whatever crate
does runtime/reference-app conformance work for #897/#898, build against
the four items above, and conformance-test against the fixture manifest.

Not yet done (tracked separately, not blocking #897/#898):
traverse-framework/registry#160 — wiring event products into the actual
static catalog UI (capability-src/catalog-builder/,
catalog/index.html). Deferred because there is currently zero live
event-product data to build or verify a real UI against. This doesn't
affect the interface above.

Full PR trail: registry#157–#164.