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.