[1.2] Decide whether Registry Manifest should publish X-Road service profile metadata

Migrated from: https://github.com/jeremi/registry-manifest/issues/22
Original author: @jeremi
Source repository: `jeremi/registry-manifest`
Source issue: `#22`
Source labels: documentation, enhancement
Source milestone/release intent: 1.2
Target area/path: `products/manifest`

## Issue

## Context

Registry Manifest is a portable metadata and renderer kernel, not a runtime integration layer. X-Road readiness probably belongs mostly in Registry Relay, Registry Notary, and Registry Platform. Still, Manifest may be the right place to publish optional static service-profile metadata if that helps operators configure X-Road Security Server services consistently.

## Scope

Create a small design decision for whether Manifest should model X-Road service profile metadata at all.

Evaluate whether static metadata should include non-secret fields such as:

- service code;
- public service title and description;
- OpenAPI description URL;
- public API base URL;
- recommended health/readiness paths;
- TLS verification expectation;
- supported backend auth mode at a high level.

Also evaluate what Manifest must not publish:

- internal backend service URLs;
- Security Server private configuration;
- API keys, bearer tokens, client secrets, or mTLS private material;
- caller-specific access-right decisions.

## Possible outcomes

- No Manifest change: document that X-Road service profiles are product/operator docs only.
- Minimal Manifest extension: add optional public X-Road profile metadata and render it in catalog artifacts.
- Deferred: keep the decision open until Relay/Notary operator docs prove what metadata is actually useful.

## Acceptance criteria

- A design note records the decision and the reason.
- If Manifest changes, schema validation and renderer tests cover the new optional fields.
- If Manifest does not change, docs explain the boundary so Relay and Notary do not depend on non-existent Manifest X-Road metadata.

## Decision Needed

X-Road service profile metadata remains a product boundary decision.

## Migration Metadata

- Migrated to the public monorepo on 2026-06-25.
- Source title, body, labels, milestone/release intent, and pre-migration discussion were preserved where available.
- Code-grounded audit note: X-Road service profile metadata remains a product boundary decision.
- Private/internal references, secrets, and obvious deployment-only details were redacted instead of copied forward.

Beginnen Sie in products/manifest und prüfen Sie den verfügbaren Kontext für Registry Relay, Registry Notary und Registry Platform, um zu bestimmen, wo die Metadaten des X-Road-Service-Profils hingehören. Halten Sie die Abgrenzungsentscheidung und ihre Begründung in einer Designnotiz fest; falls Manifest geändert wird, müssen Schema-Validierung und Renderer-Tests optionale Felder abdecken, andernfalls dokumentieren Sie, dass die Metadaten außerhalb von Manifest verbleiben.

Vom Indexierungsmodell aus dem Issue-Text verfasst.