feat(portal): add dynamic service registry with manifest integration (#278)

[priyanshuvishwakarma273403]

Problem

Vault Web previously relied on a hardcoded list of services (Cloud, Password Manager) in its frontend configuration. Adding or modifying a service required editing Vault Web itself, making the portal and actual deployment prone to configuration drift.

Solution

Introduced a dynamic service registry manifest system:

1. Manifest Schema Definition: Documented a standard JSON schema (vault-service.json) in docs/service-manifest-schema.md specifying how each module describes itself (display details, route, health endpoints, required scopes, token forwarding).
2. Mock Manifests shipped: Shipped conformant manifests for cloud, passwords, and habits in the web root.
3. Registry Startup & Health Verification: Added ServiceRegistryService triggered via Angular APP_INITIALIZER to dynamically load manifests at boot and perform automated health checks on each service's health endpoint.
4. Graceful UI Degradation: Replaced hardcoded navigation links in the navbar (both desktop and mobile) with dynamically rendered items. Unreachable or missing services (such as Habits) degrade gracefully, displaying as disabled/greyed-out in the menu with an "offline" badge and descriptive tooltip.

Verification Details

• Created unit tests in service-registry.service.spec.ts to assert manifest parsing, fallback handling, and health check integration.
• Verified that all unit tests pass successfully (TOTAL: 21 SUCCESS).
• Validated that Prettier formatting and ESLint are 100% clean (0 errors/warnings).

[DenizAltunkapan]

Good direction, this is exactly what #278 asked for and the structure (manifest validation, graceful degradation, specs) is solid. No conflicts and CI is green. A few things need fixing before this can go in, mostly around deployment reality and boot behaviour.

Summary of the requested changes, details inline:

1. The manifests hardcode localhost URLs, which makes every service show as offline in any non dev deployment. That defeats the drift problem this PR sets out to solve.
2. The APP_INITIALIZER blocks app boot on all health checks with no timeout.
3. Health checks go through the token interceptor, so the auth token is sent to whatever URL a manifest declares, and a down service triggers the global backend unavailable banner at startup.
4. The navbar reads the registry once in ngOnInit, which only works because of the blocking initializer.
5. Smaller items: apiUrl is required by the interface but not validated, and the habits manifest points at a route that does not exist.

One more nit outside the diff: the PR description links to a local file path (file:///d:/...), please swap that for a repo link.

[DenizAltunkapan]

Went through 47efe67. All five points from my review are properly addressed:

• Host resolution via {host} templating and resolveUrl, including the https upgrade when the page is served over TLS
• APP_INITIALIZER no longer awaits the health checks, and both the manifest loads and the checks carry a 3s timeout
• Health checks run through a separate HttpClient built on HttpBackend, so the token interceptor and the error banners are bypassed
• Navbar is reactive now via BehaviorSubject and services$
• apiUrl is validated in isValidManifest and lines up with the schema doc

One thing to fix before I approve, and it came in with this last commit. In habits-service.json, route changed from /habits to http://{host}:8092. route is the in-app router path, not a service URL, and baseUrl already carries the host. With the new isExternalUrl branch in the navbar, habits now renders as an external anchor pointing at a bare origin instead of a router link. cloud-service.json and password-manager-service.json both kept their /cloud and /passwords paths correctly, so habits is the only one affected.

Set it back to /habits and this is good to go. The isExternalUrl handling itself is worth keeping for services that genuinely live on another origin.