docs(mtconnect): record the #823 end-to-end gate (adapter stop, Agent restart/stop/pause, genuine overrun)

docs/drivers/MTConnect.md

@@ -722,6 +722,23 @@ deliberately different, kept.
 - **Deferred live checks:** these legs ran through the driver, **not** through a deployed OtOpcUa server and an
   OPC UA client (the docker-dev rig was not used); the no-progress cap was observed via a `SampleCount` above the
   Agent's `bufferSize`, not a genuinely lapped ring buffer; no real machine tool or non-cppagent Agent was exercised.
+  **Closed by the #823 gate below**, except the real-machine / non-cppagent caveat.
+
+### End-to-end gate through a deployed server (#823, 2026-11-11, docker-dev)
+
+An MTConnect driver (`SampleCount` 1000, `HeartbeatMs` 10000, `RequestTimeoutMs` 5000) against the shared fixture,
+two raw tags (`fixture_x_pos` Double, `fixture_execution` String) referenced into a UNS equipment, deployed to the
+central pair, and two Client.CLI subscriptions on central-1 (`ns=3` equipment folder, `ns=2` raw device). Raw and UNS
+NodeIds moved together in every leg. Fixture containers were restored healthy afterwards.
+
+| Leg | What happened on the wire |
+|---|---|
+| Adapter stop | Both NodeIds `BadNoCommunication` within 1 s of the adapter dying (Agent marks items UNAVAILABLE); driver stayed Healthy. Adapter start ⇒ Good 1–2 s later. |
+| Agent restart (`docker restart`, ~12 s) | Stream lost and reconnected ~1 s; the stale cursor was refused `OUT_OF_RANGE`, the re-baseline saw the new `instanceId`, **rediscovery raised** — `/hosts` shows the **RE-BROWSE** chip. Values stayed Good (outage shorter than the comms-loss window). |
+| Agent stopped ~2 min | Values held Good-but-stale; **Bad at 118 s** (comms-loss watchdog, connection refused). Agent start ⇒ re-init on the 10 s retry, Good ~8 s after the Agent was back. |
+| Agent paused (`docker pause`) | Stream idle watchdog at 24 s (2 × 10000 + 5000); **Bad at 94 s** (watchdog); unpause ⇒ Good within ~3 s. |
+| Genuine buffer overrun | A stalling TCP proxy froze the driver's transport while 32 000 observations were injected (`AllowPut`) — the Agent's `firstSequence` passed the driver's cursor (75 856 → 77 083). On release the resume was refused `OUT_OF_RANGE`, the driver re-baselined from `/current` within 1 s and resumed; values Good, no restart misdiagnosed. A raised-count stream (count 16, interval 5 s) was **not** lapped by a 266 obs/s burst: chunks are sent back-to-back while data is pending, so `interval` does not cap throughput. |
+| `SampleCount` vs `bufferSize` (#825) | Test Connect rendered the amber "OK with warning" chip and a deploy logged the Warning (`/hosts` shows `agentBufferSize`). The same gate measured the Agent's real edge — `count = 16384` streams, `16385` is `OUT_OF_RANGE` — so the first build's "at or above" threshold was corrected to "above" (pinned live by `Test_Connect_warns_when_SampleCount_exceeds_the_live_agents_buffer_size`). |
 
 ## Known limitations
 

tests/Drivers/ZB.MOM.WW.OtOpcUa.Driver.MTConnect.IntegrationTests/MTConnectAgentIntegrationTests.cs

@@ -953,7 +953,7 @@ public sealed class MTConnectAgentIntegrationTests(MTConnectAgentFixture agent)
     ///     <c>bufferSize + 1</c>, so both sides of that edge are checked against the Agent itself as well as the probe.
     /// </summary>
     [Fact(Timeout = TestTimeoutMs)]
-    public async Task Test_Connect_warns_when_SampleCount_reaches_the_live_agents_buffer_size()
+    public async Task Test_Connect_warns_when_SampleCount_exceeds_the_live_agents_buffer_size()
     {
         SkipIfDown();