feat(hosts): surface per-host connectivity on /hosts; drop the unwritable table (#521)

`IHostConnectivityProbe` was a dead surface: eleven drivers implement it, `GetHostStatuses()`
had ZERO production call sites, and `OnHostStatusChanged` had no subscriber outside the Galaxy
driver's own aggregator. Per-host connectivity was computed by every driver and read by nobody.

The issue offered "build the publisher or delete it". The publisher as its entity doc described
it — driver nodes upserting `DriverHostStatus` rows — is not buildable: per-cluster mesh Phase 4
gates `AddOtOpcUaConfigDb` on the `admin` role, so a driver-only node has no ConfigDb connection
to write rows with. So the capability is kept and the transport changed.

`DriverHealthChanged.HostStatuses` now carries the probe result to `/hosts` as a Hosts column.
That channel already reached the page, already survives the mesh split via the Phase 5 gRPC
telemetry stream, and already replays a last-value snapshot on re-subscribe — so per-host state
re-primes after a reconnect without a durable store. Both halves of the interface finally do
what they are for: the event triggers a prompt publish, the pull is the source of truth.

The point of the column is the case the driver-level state chip structurally cannot express: a
multi-device driver stays aggregate-Healthy while ONE of its devices is unreachable.

Two traps, both pinned by tests that were falsified against the prod code:

- The host digest MUST be in the publish fingerprint. On a single-host-down transition every
  other fingerprint component is unchanged, so the dedup would swallow exactly the publish
  carrying the news — the trap that already bit the rediscovery signal. Removing it turns the
  guard test red, verified.
- null (no probe) must stay distinct from empty (probe with no hosts). proto3 cannot tell an
  absent repeated field from an empty one, hence the explicit `has_host_statuses` flag;
  collapsing them would render every probe-less driver as one whose devices are all fine.

Dropped: the DriverHostStatus entity, enum, DbSet, model config and table (migration
DropDriverHostStatusTable — empty on every deployment, so the scaffolder's data-loss warning is
moot, and Down() recreates it exactly).

Found en route, NOT fixed here: `DriverInstanceResilienceStatus` is the identical defect — no
writer, no reader, only a DbSet declaration, while the live data rides the
`driver-resilience-status` telemetry channel. Its doc-comment now states that rather than
describing the sampler and AdminUI join that were never built. Filed as #524 rather than widening
this schema change beyond what was asked.

Claude-Session: https://claude.ai/code/session_015p7wGqy3YpZNCpDzTpGMKo

docs/Telemetry.md

@@ -88,6 +88,38 @@ single stream per (central, driver-node) pair carries all four, rather than one
 Proto field evolution is additive-only (never renumber/reuse a tag), locked by a contract test that
 reflects over the `oneof` cases.
 
+### Per-host connectivity rides `driver-health` (Gitea #521)
+
+`DriverHealthChanged.HostStatuses` carries each driver's `IHostConnectivityProbe.GetHostStatuses()`
+result, rendered as the **Hosts** column on `/hosts`. It exists to show the one thing the driver-level
+state chip structurally cannot: a **multi-device driver stays aggregate-`Healthy` while one of its
+devices is unreachable**. A FOCAS or AbLegacy instance owning several PLCs previously hid that
+entirely.
+
+Three things to know before touching it:
+
+- **This deliberately does NOT go through SQL.** A `DriverHostStatus` table existed, with an entity
+  doc describing a publisher hosted service that upserted rows from each driver node. That publisher
+  was never written, and **per-cluster mesh Phase 4 made it unbuildable as described** — `Program.cs`
+  gates `AddOtOpcUaConfigDb` on the `admin` role, so a driver-only node has no ConfigDb connection to
+  write rows with. The table was dropped (migration `DropDriverHostStatusTable`); it was empty on
+  every deployment. This channel needs no DB and already survives the mesh split.
+- **null ≠ empty, on the wire too.** Null means "the driver has no probe"; an empty list means "it has
+  one that currently knows no hosts". proto3 cannot distinguish an absent repeated field from an empty
+  one, so `DriverHealth.has_host_statuses` carries that bit explicitly. Collapsing the two would render
+  every probe-less driver as one whose devices are all fine.
+- **The host digest is part of the publish fingerprint, and must stay there.** `PublishHealthSnapshot`
+  dedups on that fingerprint, and on a single-host-down transition *every other component is
+  unchanged* — so without it the dedup swallows precisely the publish carrying the news. Same trap
+  that bit the rediscovery signal; pinned by
+  `DriverInstanceActorHostStatusTests.A_single_host_going_down_is_not_swallowed_by_the_unchanged_health_dedup`.
+  The digest is a flattened, host-name-ordered **string** for the converse reason: a tuple holding an
+  `IReadOnlyList` compares by reference and would re-publish on every 30 s heartbeat forever.
+
+⚠️ **`DriverInstanceResilienceStatus` is the same defect, still open.** That table also has no writer
+and no reader — the only reference in the repo is its DbSet declaration — while the live data reaches
+the AdminUI over the `driver-resilience-status` channel above. Keep-or-delete is Gitea **#524**.
+
 ## The three deferred channels (NOT migrated in Phase 5 — do not read this as "seven done")
 
 The program sketch originally named seven observability topics for Phase 5. Three were scoped out,