feat(health): serve MapZbHealth on site nodes

Site nodes served no health surface at all — gRPC on the HTTP/2-only listener and
/metrics on the HTTP/1.1 one — so nothing outside the cluster could ask a site
node whether it was ready or which half of the pair was active. The family
overview dashboard probes every instance the same way, and this is the one gap.

Three checks, registered in SiteServiceRegistration.Configure (not Program.cs, so
the composition-root tests that build this graph actually cover them) and mapped
by app.MapZbHealth() on the site's HTTP/1.1 listener (default :8084) alongside
/metrics:

  akka-cluster  [Ready]  the shared AkkaClusterHealthCheck. Also carries the
                         cluster-view data (leader/memberCount/...) the dashboard
                         reads, free with ZB.MOM.WW.Health 0.2.0.
  localdb       [Ready]  NEW SiteLocalDbHealthCheck — SELECT 1 through the
                         registered ILocalDb. Site has no EF context; central's
                         DatabaseHealthCheck<ScadaBridgeDbContext> is central-only.
                         Replication state rides along as data ENRICHMENT only:
                         replication is default-OFF, so failing on it would mark
                         every correctly-configured node unready.
  active-node   [Active] NEW SitePairActiveNodeHealthCheck, delegating to
                         IClusterNodeProvider.SelfIsPrimary. Deliberately NOT
                         central's OldestNodeActiveHealthCheck: that one calls
                         SelfIsOldest(cluster) with no role argument and would
                         compute "oldest" across the wrong member set on a mesh
                         carrying more than one site.

Anonymous, as central's are: the site pipeline runs no authentication middleware
and has no FallbackPolicy, so nothing extra was needed.

Also bumps ZB.MOM.WW.Health* 0.1.0 -> 0.2.0 (central gains data.leader for free).

Tests: SiteHealthCheckTests builds the REAL site container and activates every
registration through its factory (exact-set names, one tier tag each, resolved
types, central-only checks absent behind a positive control) plus behaviour for
both new checks. SiteHealthEndpointTests boots the real site Program over
WebApplicationFactory and proves the endpoints are MAPPED — without it, deleting
MapZbHealth would leave every registration test green while site nodes 404'd.

Prereq for scadaproj docs/plans/2026-07-22-overview-dashboard-impl-plan.md Phase 1.

src/ZB.MOM.WW.ScadaBridge.Host/Program.cs

@@ -634,6 +634,20 @@ try
         // must be present before the Map* calls on the site role.
         app.UseRouting();
 
+        // Map the canonical three-tier health endpoints on the site node:
+        //   /health/ready  — akka-cluster (site-pair membership, and the cluster-view data the
+        //                    family overview dashboard reads) + localdb (the consolidated site
+        //                    store — the only database a site node has).
+        //   /health/active — active-node = this site pair's primary; 200 on the primary, 503 on
+        //                    the standby, the same contract central publishes.
+        //   /healthz       — bare process liveness.
+        // Checks are registered in SiteServiceRegistration.Configure. All three endpoints are
+        // anonymous and use the canonical ZbHealthWriter JSON; the site pipeline runs no
+        // authentication middleware and has no FallbackPolicy, so nothing extra is needed to keep
+        // them reachable. They are served on the HTTP/1.1 listener (metricsPort, default :8084)
+        // alongside /metrics — the gRPC listener is HTTP/2-only and unusable by a plain HTTP client.
+        app.MapZbHealth();
+
         // Observability — mount the always-on Prometheus /metrics scrape endpoint.
         // AddZbTelemetry (in SiteServiceRegistration.Configure → BindSharedOptions)
         // wires the OTel Resource + standard instrumentation + Prometheus exporter;