[Feature]: Service registry manifest per module for dynamic service integration

[DenizAltunkapan]

Problem

Vault Web is the portal that unites the other services (cloud, password manager, chats, habits), but it currently has to know about each service through hardcoded frontend and deployment configuration. Adding or moving a service means editing Vault Web itself: its URL, its icon, which scopes it needs, where its health endpoint is. This does not scale as the ecosystem grows and makes it easy for the portal and the actual deployment to drift apart.

Example: a new module is added to the stack. Today someone has to wire its URL and metadata into the Vault Web frontend by hand. It should be enough for the module to describe itself and for Vault Web to pick it up.

Proposed solution

Define a small service registry manifest that each module ships, and have Vault Web build its view of the ecosystem from those manifests instead of hardcoded config.

Proposed manifest (for example vault-service.json) per module:

• name and display name
• base URL and icon
• health endpoint
• required scopes
• token forwarding expectations (how the gateway should pass identity to it)

Scope:

• agree a minimal manifest schema and document it (a good fit for server-docs)
• each module provides its manifest
• Vault Web reads the manifests and renders available services from them, rather than a hardcoded list
• unknown or unreachable services degrade gracefully in the portal

Notes:

• This should come after the gateway-centric auth work (Migrate to gateway-centric auth (remove per-service JWT validation) auth-api-gateway#38): the scopes and token-forwarding fields in the manifest only make sense once the gateway owns identity and audience boundaries. Sequence auth first, then dynamic registration.
• This is deployment-facing as well as portal-facing, so the deploy repo is a stakeholder even though the portal-side work lives in vault-web.

Acceptance criteria

• A minimal service manifest schema is defined and documented.
• At least one module ships a manifest that conforms to the schema.
• Vault Web renders available services from manifests rather than a hardcoded list.
• A missing or unreachable service degrades gracefully in the portal.
• The scopes and token-forwarding fields align with the gateway auth model (chore(deps-dev): bump @typescript-eslint/parser from 8.35.1 to 8.38.0 in /frontend #38).

Related: depends on the gateway-centric auth migration (Vault-Web/auth-api-gateway#38); the schema is a documentation candidate for server-docs.