Add platform health dashboard

[andreasohlund]

Summary

• add the first in-app Platform health page, nav item, support modal, and dev-mock controls
• introduce a shared frontend platform model used by Platform health and Platform Capabilities
• align dashboard capability status badges with Platform health navigation, add status-specific nav tooltips, link platform health instance names to their API URLs, hide built-in platform custom checks by default with a page toggle, infer platform health from hidden built-in checks, remove duplicated instance widgets from capability cards, and remove footer ServiceControl/Monitoring widgets

Design decisions

• Use a shared frontend platform model/store as the source of truth for both Platform health and Platform Capabilities.
• PlatformModelStore exists as the shared aggregation and normalization layer for platform state: it composes ServiceControl primary data, remote instances, and Monitoring state into one reusable PlatformModel, so feature stores and views do not each fetch, infer roles, or duplicate fallback logic independently.
• Keep transport concerns in the API clients: PlatformModelStore should compose typed data from serviceControlClient and monitoringClient rather than issuing direct fetches itself.
• Prefer purpose-specific client methods for the shared platform model inputs (serviceControlClient.getRoot(), serviceControlClient.getRemoteInstances(), monitoringClient.getMonitoringRoot()) so PlatformModelStore stays declarative and the client boundary is symmetric across ServiceControl and Monitoring.
• Keep the concrete ServiceControl root shape with serviceControlClient instead of re-declaring an ad hoc root DTO inside PlatformModelStore.
• Keep Platform health focused on instance and topology visibility, not configuration-readiness guidance.
• PlatformModel.monitoring remains PlatformInstance | null and is shared by both Platform health and Platform Capabilities.
• Do not model the multi-region concept explicitly in the shared frontend model; derive the needed behavior from instance roles instead (primary-error, remote-error, remote-audit, monitoring).
• Remove the prototype warnings concept for now and keep the shared platform model focused on instance state.
• Remove success-path defaults in mapPrimary; when the primary root request succeeds, PlatformModelStore now trusts the ServiceControl root payload for name, platform_health_status, and platform_health_version, while keeping the separate fetch-failure fallback path.
• Hide built-in product/platform custom checks from the Custom Checks page, dashboard tile, and menu badge by default.
• Expose a discrete Show platform custom checks toggle on the Custom Checks page so operators can still inspect those hidden built-in checks when needed.
• Use the same built-in product/platform custom check catalog for two purposes: filtering those checks out of the Custom Checks UI by default and feeding them into Platform health as secondary health signals.
• Key the built-in platform custom check catalog by category + custom_check_id; ServiceControl reuses some custom check IDs across categories, so the frontend cannot treat custom_check_id alone as a unique semantic identifier.
• Keep Platform health inference from built-in platform custom checks page-specific rather than mutating the shared platform model and changing Platform Capabilities semantics.
• Keep PlatformHealthRow page-specific rather than pushing table-only display semantics into the shared model.
• Keep the implementation frontend-only and mock-driven; do not introduce a new ServicePulse backend endpoint in this PR.
• Keep a single platform-health startup mock scenario, and use window.__platformHealth runtime helpers to switch topology, status, and custom-check conditions live instead of maintaining multiple startup scenario variants.
• In Platform Capabilities, show grey Not configured badges for instance-not-configured states and keep capability-specific readiness semantics there.
• In Platform Capabilities, keep Monitoring card status Available whenever Monitoring is configured and connected; use the Metrics indicator to show whether endpoints are currently sending throughput data.
• In Platform Capabilities, keep Recoverability card status Available whenever the primary ServiceControl instance is healthy; use the FailedMessages indicator to warn when multi-region topology makes cross-region failure management read-only.
• Remove per-instance widgets from Platform Capabilities cards so instance-level visibility lives on the Platform health page, while capability-specific widgets such as Messages and Metrics stay on the cards.
• Platform health nav icon precedence is danger > warning > info for outdated-only cases, and the menu item tooltip follows the same status precedence.
• Platform health instance names link directly to each instance apiUrl from the shared platform model.
• Keep topology scenarios and custom check scenarios independently switchable in dev mocks so mixed platform-check and user-check states can be exercised without multiplying mock scenario names.

Keep this section up to date as implementation and product decisions evolve.

Test scenarios

See docs/frontend/platform-health-page.md for:

• dev-mock startup and runtime helpers
• topology and custom-check scenarios
• manual checks
• focused Platform health specs

Follow-ups

• Make custom check failures correlated to specific platform instances instead of only category-level targeting.

[andreasohlund]

Not sure about this one, needs disussion

[andreasohlund]

Needs discussion: should we move this to the health page as well?

[andreasohlund]

This is now presented on the platform health page