docs: correct stale LDAP-role, host-probe, resilience-table, Bad-value claims; fix tasks.json (#624)

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

docs/drivers/Calculation.md

@@ -121,7 +121,8 @@ Notes worth knowing before authoring against this:
 ## Error semantics
 
 An evaluator failure publishes **Bad quality carrying the last-known value** — the value is not
-zeroed, because a stale-but-flagged reading is more useful to an operator than a fabricated one. It
+zeroed, so the node holds it server-side for the next Good re-publish and the `(value, status)` dedup. (Over the wire the
+OPC UA SDK nulls the value of a Bad-status read, so a client sees only the Bad status — see `docs/DriverLifecycle.md`.) It
 publishes:
 
 - **once per Good→Bad transition**, not on every failed evaluation (a permanently broken script does

docs/drivers/MTConnect.md

@@ -378,10 +378,11 @@ for anything beyond values-and-conditions.
    — it would materialise nodes nobody approved and no deployment artifact
    records.
 
-   **`IHostConnectivityProbe` is still unconsumed** — `GetHostStatuses()` has
-   no production call site and nothing writes a `DriverHostStatus` row. That
-   half remains a fleet-wide gap affecting every driver that implements it
-   (Gitea #521).
+   **`IHostConnectivityProbe` is consumed** (Gitea #521, closed) —
+   `DriverInstanceActor` subscribes `OnHostStatusChanged`, pulls
+   `GetHostStatuses()` fresh, and the result rides `DriverHealthChanged` to
+   the AdminUI `/hosts` page (no SQL; the `DriverHostStatus` table was
+   dropped). See `docs/Telemetry.md`.
 2. **`RawTagEntry.DeviceName` is accepted on the wire shape but ignored for
    routing.** One driver instance owns exactly one Agent client scoped by
    `MTConnectDriverOptions.DeviceName` (the top-level config key); the

docs/drivers/Mqtt.md

@@ -428,7 +428,7 @@ which is archreview 05/STAB-18.
 
 - **Connection loss stales, keeping the value.** On the `Connected → Reconnecting` edge
   `MqttConnection.ConnectionLost` fires, and both ingest paths mark every **already-observed**
-  reference `BadNoCommunication` with its **last value retained** and publish the change. A
+  reference `BadNoCommunication` with its **last value retained** (server-side; a client reads the Bad status with a null value) and publish the change. A
   never-observed reference (still `BadWaitingForInitialData`) and an already-Bad one are left alone.
   The event does **not** fire for a failed *initial* connect or during dispose — neither is an outage.
 - **Every (re)subscribe pushes the cached snapshots.** `SubscribeAsync` republishes each observed