Define Registry Relay 1.0 default and optional feature build matrix

[jeremi]

Context

Registry Relay v0.13.0's published image intentionally excludes the beta attribute-release Cargo feature. Solmara Lab's NIA/eSignet configuration requires that API, so Solmara currently has to build a source-pinned Relay binary from the exact release tag instead of using the released image.

That bridge preserves source provenance, but it fragments the release contract and evidence. For 1.0, adopters should be able to determine which capabilities are in the default build, which are supported optional profiles, and which remain experimental. Solmara should be able to consume a released, evidenced image for its eSignet path.

Goal

Define and implement the Registry Relay 1.0 build and publication contract for default and optional capabilities.

The preferred direction is a stable default image plus narrowly named capability variants where needed. Do not publish a generic full or --all-features image because that creates an unclear and expanding support surface.

Scope

• Inventory every Relay Cargo feature and its associated API, configuration, persistence, and operational surface.
• Classify each feature as:
  • included in the stable default build;
  • supported as an optional released capability profile;
  • experimental or unsupported for production.
• Decide the exact published image variants and stable names.
• Decide whether attribute-release is a first-class released variant for 1.0 so Solmara NIA/eSignet can use an official image.
• Define the compatibility and support lifecycle for each variant.
• Generate and publish OpenAPI artifacts that match each released variant.
• Record the source revision and exact feature set as OCI image metadata.
• Produce SBOM, vulnerability scan, signature, and provenance evidence independently for every published variant.
• Keep release builds isolated so Cargo feature unification cannot accidentally expand a variant.
• Make required runtime capabilities visible during configuration authoring or preflight, with a clear failure before service startup when a configuration is incompatible with the selected image profile.
• Document how adopters select, pin, upgrade, and verify a capability profile.
• Replace Solmara's v0.13 source-build bridge with the official immutable release image once available.

Acceptance criteria

• A checked-in feature matrix names every Relay feature and its 1.0 classification.
• Release manifests and workflows define the exact feature set for every binary and image variant.
• No published variant is built with --all-features.
• Each variant has configuration/startup, health, smoke, and OpenAPI drift tests.
• Each image is published by immutable digest with its own SBOM, scan result, signature, and provenance.
• Image metadata exposes the source revision and exact feature set.
• registryctl authoring/reporting exposes required runtime capabilities, or a preflight check rejects an unsupported image profile before deployment.
• The support and compatibility policy for optional variants is documented.
• Solmara's NIA/eSignet live proof runs against the exact digest of an official released Relay variant without compiling Relay in the Solmara repository.