docs(mtconnect): correct the MaintenanceMode note; record status-code parity pre-verification

docs/plans/2026-07-24-mtconnect-driver.md

@@ -940,13 +940,31 @@ or bind `127.0.0.2`), (b) drive `:9220` from an incognito/separate browser profi
 Note the RawPath keying is already proven at the driver seam by the live integration test above;
 what leg 5 adds is the `DeploymentArtifact` → address-space → OPC UA materialisation on top.
 
-**Two incidental findings from the rig work, worth separate follow-up:**
+**Incidental findings from the rig work:**
-1. **`ClusterNode` in this schema has no `MaintenanceMode` column** (nor `AkkaPort`/`GrpcPort`),
+1. ~~`ClusterNode` has no `MaintenanceMode` column, so CLAUDE.md is ahead of the migration.~~
-   although CLAUDE.md documents `MaintenanceMode` as the landed maintenance hatch and the mesh
+   **CORRECTED — this was my error, not a repo inconsistency.** The migration
-   Phase-1 columns as present. Reducing the seeded topology required deleting the SITE-A/SITE-B
+   `20260722125506_AddClusterNodeMaintenanceMode` exists on master, along with `AkkaPort`/`GrpcPort`.
-   rows instead. Either the doc or the migration is ahead of the other — reconcile.
+   **This branch is 39 commits behind master** (base `963eec1b`, master `28c28667`) and simply
+   predates them, so the isolated stack's schema lacked the column and I reduced the seeded topology
+   by deleting the SITE-A/SITE-B rows instead. CLAUDE.md is accurate. **Rebase onto master before
+   merging** — and once rebased, `MaintenanceMode = 1` on the site nodes is the correct, documented
+   hatch for a partial-topology live gate (it is what the SQL-poll driver's gate used), in place of
+   the row deletion I resorted to.
 2. `sqlcmd` against this schema needs `-I` (`SET QUOTED_IDENTIFIER ON`); without it every DML
    statement fails with `Msg 1934` because of the filtered/computed indexes.
+3. **Status-code parity is pre-verified against master's new guard.** Master gained
+   `StatusCodeParityTests`, which reflects over every `ZB.MOM.WW.OtOpcUa.Driver.*.dll` in its bin for
+   status-shaped `const uint` fields — including `private const` on `internal` types — and checks each
+   against `Opc.Ua.StatusCodes`. Task 16 added the `Driver.MTConnect` ProjectReference to that same
+   test project, so this driver's constants are in scope. All eight were verified against the pinned
+   SDK assembly directly: `BadCommunicationError 0x80050000`, `BadNoCommunication 0x80310000`,
+   `BadNodeIdUnknown 0x80340000`, `BadNotConnected 0x808A0000`, `BadNotSupported 0x803D0000`,
+   `BadOutOfRange 0x803C0000`, `BadTypeMismatch 0x80740000`, `BadWaitingForInitialData 0x80320000`
+   — **0 mismatches**. Note the guard only sees *named* constants; an inline status literal at a call
+   site is invisible to it, so keep hoisting them.
+4. **The separately-tracked `BadTypeMismatch` defect in FOCAS/TwinCAT/AbLegacy/AbCip is already fixed
+   on master** (issue #497 grew it to 16 wrong constants across 6 drivers). This driver independently
+   chose the correct `0x80740000` and pinned it with a mutation test, so the two agree; no action.
 
 **Teardown when done:**
 ```bash