docs(observability): record ZB.MOM.WW.Telemetry adoption across 3 apps; correct false MxGateway logging-status claim

All 3 apps adopted on branch feat/adopt-zb-telemetry (behaviour-preserving).
Records the per-repo result + accepted scope deviations (ScadaBridge keeps
LoggerConfigurationFactory + TraceContextEnricher instead of AddZbSerilog;
MxGateway keeps GatewayLogScope, exposes redaction via ILogRedactor seam) and
deferred follow-ons (#6 ms->s, #7 meter rename, #9 app instruments, OTLP, and
the new ScadaBridge Site-node HTTP/1.1 metrics-listener item). Corrects the
prior false 'MxGateway logging adopted on its own branch' claim — that migration
actually landed in this pass.

components/observability/GAPS.md

@@ -181,3 +181,47 @@ app is opt-in and tracked here, not forced.
   unit migration (Gap U1) and the Meter rename (Gap N1) are deferred from the initial MxGateway
   adoption (Task #9). They are breaking dashboard/alert changes requiring ops coordination and
   are tracked as separate backlog items #6 and #7 in the adoption backlog above.
+
+## Adoption status — 2026-06-01 (DONE)
+
+`ZB.MOM.WW.Telemetry` + `ZB.MOM.WW.Telemetry.Serilog` (`0.1.0`) were adopted across **all three**
+sister apps in one pass, behaviour-preserving. Each adoption landed on a per-repo branch
+`feat/adopt-zb-telemetry` (one commit per task). Plan + design:
+[`docs/plans/2026-06-01-telemetry-library-adoption.md`](../../docs/plans/2026-06-01-telemetry-library-adoption.md).
+
+> **Correction:** the prior claim that *"MxAccessGateway logging was adopted (MEL → Serilog) on its
+> own branch"* was **false on `main`** — MxGateway was still MEL-only, and its `MxGateway.Server`
+> meter was never exported. The full MEL→Serilog migration **and** the metrics export both landed
+> in this 2026-06-01 pass.
+
+| Repo | `AddZbTelemetry` (Resource + std instrumentation + Prometheus) | `/metrics` | Logging | Meter (unchanged) |
+|---|---|---|---|---|
+| **OtOpcUa** | ✅ replaced hand-rolled `ObservabilityExtensions` | ✅ `/metrics` (path unchanged) | ✅ `AddZbSerilog` (sinks moved to `appsettings`; `LogContextEnricher` kept) | `ZB.MOM.WW.OtOpcUa` |
+| **ScadaBridge** | ✅ added in `BindSharedOptions` (both Central + Site roots) | ✅ Central; mapped on Site too (see follow-on) | ⚠️ **kept `LoggerConfigurationFactory`** + added shared `TraceContextEnricher` — did **not** adopt `AddZbSerilog` | (none yet; #9) |
+| **MxAccessGateway** | ✅ exports existing `GatewayMetrics` | ✅ new `/metrics` | ✅ MEL→`AddZbSerilog`; `GatewayLogRedactor` exposed via `ILogRedactor` seam (`GatewayLogRedactorSeam`); `GatewayLogScope`/middleware kept as-is | `MxGateway.Server` (name + `ms` units unchanged) |
+
+### Accepted scope decisions (deviations from the original backlog)
+
+- **ScadaBridge keeps `LoggerConfigurationFactory` (backlog #5 revised).** The factory implements a
+  documented governance contract (REQ-HOST-8 / Host-011/014/020/022): `ScadaBridge:Logging:MinimumLevel`
+  is the floor and **overrides** `Serilog:MinimumLevel`, with operator warnings. `AddZbSerilog`
+  hard-codes `MinimumLevel.Is(Information)` before `ReadFrom.Configuration`, which would invert that
+  precedence and silently drop the knob. So ScadaBridge keeps the factory and only **adds the shared
+  `TraceContextEnricher`** to it — gaining trace↔log correlation without regressing the contract. Full
+  `AddZbSerilog` adoption for ScadaBridge would first require teaching the shared bootstrap to accept a
+  caller-supplied minimum-level governance hook.
+- **MxGateway keeps `GatewayLogScope` + request-logging middleware as-is.** The Serilog MEL provider
+  captures MEL `BeginScope` dictionaries as structured properties, so the scope/correlation code keeps
+  producing the same properties under Serilog. Only the provider swap + the `ILogRedactor` adapter were
+  needed.
+
+### Deferred (still open follow-ons)
+
+- **#6** MxGateway histogram `ms`→`s`, **#7** Meter rename `MxGateway.Server`→`ZB.MOM.WW.MxGateway`
+  (both break dashboards — ops-coordinated).
+- **#9** ScadaBridge application instruments (`ScadaBridgeTelemetry` + `scadabridge.*`).
+- **#10/#11** OTLP exporter wiring; OtOpcUa trace export is still a no-op (Prometheus is metrics-only).
+- **NEW — ScadaBridge Site-node `/metrics` scrape:** the Site role's Kestrel is HTTP/2-only (gRPC),
+  so the mapped `/metrics` is not HTTP/1.1-scrapable on that listener. The in-process metrics + Resource
+  still apply; Central serves `/metrics` normally. A follow-on should add a dedicated HTTP/1.1 (or
+  `Http1AndHttp2`) listener/port for site-node scraping.