Replace internal platform health custom checks with an explicit API

[andreasohlund]

We should move ServiceControl’s internal platform health signals off the custom checks channel and onto an explicit API that ServicePulse consumes directly.

Follow-up to Particular/ServicePulse#2317

Why

Today, ServiceControl self-monitoring is implemented as custom checks, and ServicePulse has to special-case them by:

• classifying internal check IDs in ServiceControl
• hiding them from the normal custom checks UI
• reinterpreting them in the Platform Health dashboard

That creates unnecessary coupling between platform health and customer-facing custom checks. It also makes platform health depend on the same transport-based delivery semantics that are appropriate for customer checks, but not ideal for internal product health signals.

Current state

• ServiceControl publishes internal health as custom checks.
• ServicePulse uses those checks to derive Platform Health status.
• The docs already describe Platform Health as a distinct concept from normal custom checks.
• ServiceControl and ServicePulse already communicate over HTTP for other platform data, so an explicit API fits the existing architecture.

Proposed direction

Introduce a dedicated platform health API in ServiceControl that returns:

• instance health state (consider introducing a severity level for instance health issues)
• version / upgrade data
• alert details
• enough metadata for ServicePulse to render Platform Health without inferring state from internal custom checks
• consider adding new integration events for health issues since moving away from custom checks means that customers subscribed to custom checks events will no longer get notified

ServicePulse should use this API as the source of truth for Platform Health.

Migration plan

1. Add the explicit API in ServiceControl.
2. Update ServicePulse to read Platform Health from the API.
3. Keep the existing internal custom checks as a temporary fallback for compatibility.
4. Remove the special-case internal custom check classification once the new API is established across supported versions.
5. Update docs to describe platform health separately from customer custom checks.

Benefits

• Removes hardcoded internal custom check ID classification
• Separates product health from customer extension points
• Reduces transport coupling
• Makes Platform Health easier to evolve independently
• Clarifies the boundary between customer monitoring and ServiceControl self-monitoring