Add organization-level /releases/ and /distribution/ views

[szmyty]

Outcome

Add first-class organization-level /releases/ and /distribution/ views that distinguish what was released from where a version is actually obtainable and install-verified across platforms/channels.

This is the fleet counterpart to the delivered repository /releases/ work in egohygiene/relay#81 and a bounded child of #27 and #30.

Primary questions

• What has shipped, from which reviewed source revision, with what provenance?
• Which version is available through each applicable channel/platform?
• Was it built, published, discoverable, and clean-install verified?
• Which evidence is pending, stale, blocked, failed, unknown, experimental, or not applicable?

Data and ownership

Consume the versioned Observatory distribution model from egohygiene/observatory#13 plus canonical release evidence. Repositories/registries remain release truth; Relay owns reusable evidence workflows; Pace owns rollout.

Required experience

Releases

• Release trains/tags, source revisions, contents, evidence, deployments, rollback links, and unreleased work.
• Provenance/SBOM/signature/check links where public.
• Clear prerelease, current, superseded, failed, missing, stale, and unknown states.

Distribution

• Repository/component rows and applicable platform/channel columns.
• Build, publication, discoverability, and install-verification states shown independently.
• Package coordinates, observed/current versions, support tier, architecture/runtime, evidence age, and remediation owner.
• Explicit propagation-pending, version-drift, credential-blocked, experimental, unavailable, unsupported, and not-applicable states.

Cross-link the two views without claiming a GitHub release proves channel publication or a package listing proves a clean install.

Acceptance criteria

• Canonical organization /releases/ and /distribution/ surfaces are registered through egohygiene/hygiene#25.
• The views consume Observatory Recover and route the Filament architecture concept #13 and canonical release evidence rather than scraping registries in the browser.
• Release, build, publication, discoverability, deployment, and install verification remain distinct.
• Version drift and evidence freshness are visible per channel/platform.
• Unknown, stale, blocked, propagation-pending, failed, experimental, unsupported, unavailable, and not-applicable remain distinct.
• Every material claim deep-links to release/package/workflow/provenance evidence where public.
• Public output cannot leak private packages, repositories, credentials, or publisher configuration.
• Rust CLI, Python/package, static publication, partial rollout, and failed-channel fixtures pass.
• Mobile, keyboard, screen-reader, reduced-motion, no-color-only, matrix-overflow, and large-fleet behavior is verified.

Dependencies / related

• Parent shell: Evolve Organization Intelligence into a modular fleet control plane #27
• Master epic: [EPIC] Finish Repository Intelligence, Organization Intelligence, and site control-plane surfaces #30
• Route registry: Define the canonical public-site surface and route registry hygiene#25
• Fleet read model: feat(distribution): publish fleet package availability, version, and installability dashboards observatory#13
• Repository releases view: Render shipped evidence at /releases/ in Repository Intelligence relay#81
• Reusable distribution workflows: feat(distribution): publish reusable cross-platform build, package-manager, and install-verification matrix workflows relay#48
• Release adoption/drift: feat(releases): observe organization release-convention adoption and drift pace#17
• Distribution rollout: feat(distribution): roll out the universal tool distribution profile across eligible repositories pace#19

Non-goals

• Publishing packages or holding registry credentials.
• Treating all channels/platforms as universally applicable.
• Equating a tag with publication or a package listing with install verification.
• Replacing registry/repository release truth.