docs(mtconnect): describe the fixed browse-commit coercion type (#560)

The comments and docs that described Driver.MTConnect-003 as live at HEAD would
have been wrong the moment 64be41d8 landed:

- code-reviews/Driver.MTConnect/findings.md — Driver.MTConnect-003 Resolved,
  with the fixing commit; module open-finding count 5 -> 4.
- code-reviews/Driver.MTConnect.Contracts/findings.md — the one clause inside
  Contracts-001's prose that asserted 003 was Open.
- docs/drivers/MTConnect.md — the coercion-precedence warning now states that a
  browse-committed tag resolves at step 1 CARRYING the step-3 answer, and that
  step 3 remains the rescue for a hand-authored / CSV / API blob with no type.
- MTConnectDriver.BuildBinding, MTConnectDataTypeInference and
  MTConnectDriverOptions.RawTags remarks — same correction, each keeping a short
  historical note of what the defect was so a reader meeting the old blobs still
  understands them.

Comment-only in src; the driver suite (538) and AdminUI suite (1474) re-run green.

code-reviews/Driver.MTConnect.Contracts/findings.md

@@ -61,7 +61,7 @@ false premise concealed a live defect rather than merely misinforming a reader.
 
 The second is what makes this worth recording rather than a tidy-up: a reader auditing the browse
 path would have taken that remark as evidence the case was handled. The underlying defect is
-recorded as `Driver.MTConnect-003` (Open, fix belongs in `RawBrowseCommitMapper`).
+recorded as `Driver.MTConnect-003` (Resolved `64be41d8`, 2026-08-10, in `RawBrowseCommitMapper`).
 
 **Recommendation:** Correct both remarks to describe the callers that exist, and — rather than
 deleting the precedence rule, which is still correct for hand-authored, CSV-imported and API-authored

code-reviews/Driver.MTConnect/findings.md

@@ -7,7 +7,7 @@
 | Review date | 2026-08-10 |
 | Commit reviewed | `b990adae` |
 | Status | Complete |
-| Open findings | 5 |
+| Open findings | 4 |
 
 ## Checklist coverage
 
@@ -110,7 +110,7 @@ requested `/probe`, expected `/VMC-1/probe`) and the control
 | Severity | High |
 | Category | Correctness & logic bugs |
 | Location | `src/Server/ZB.MOM.WW.OtOpcUa.AdminUI/Uns/RawBrowseCommitMapper.cs:256` (cause) · `src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.MTConnect/MTConnectDriver.cs:3286` (`BuildBinding` precedence) |
-| Status | Open |
+| Status | Resolved |
 
 **Description:** **Every browse-committed MTConnect tag is coerced to `String` at runtime while its
 OPC UA node is typed from the probe inference**, so a browsed `SAMPLE` publishes text into a
@@ -150,9 +150,16 @@ behaviour for AbCip/TwinCAT/FOCAS, and assert the **pair** — that the tag row'
 blob's coercion type agree — rather than either alone: asserting only the blob would pass against a
 mapper that had stopped setting the row's type.
 
-**Resolution:** _(open — the fix belongs in `ZB.MOM.WW.OtOpcUa.AdminUI`, outside this review's
-modules; tracked as Gitea **#560**. The stale premises this defect invalidated inside these two
-modules are corrected under `Driver.MTConnect-008` and `Driver.MTConnect.Contracts-001`.)_
+**Resolution:** Fixed `64be41d8`, 2026-08-10 (Gitea **#560**) — cross-module, in
+`ZB.MOM.WW.OtOpcUa.AdminUI`: `RawBrowseCommitMapper.MapLeaf` now threads the browsed leaf's
+`driverDataType` into `BuildTagConfig`, whose MTConnect branch uses it as the `NativeType` fallback,
+so the committed blob's coercion type and the raw tag row's OPC UA type both come from the one probe
+inference — the same forwarding the AbCip / TwinCAT / FOCAS branches already did for #536. A leaf
+inferred (or reported) as `String` still commits `"dataType":"String"`, and an unusable name still
+falls back to it through the shared numeric-string / unparseable guards. Pinned by
+`RawBrowseCommitMapperTests` asserting the PAIR plus that `String` control; the stale premises this
+defect left inside these two modules are corrected under `Driver.MTConnect-008` and
+`Driver.MTConnect.Contracts-001`.
 
 ### Driver.MTConnect-004