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.

docs/drivers/MTConnect.md

@@ -194,15 +194,23 @@ into) is resolved in this order, first non-null wins:
    (category/type/units/representation → `DriverDataType`).
 4. `DriverDataType.String` — the coercion that cannot fail.
 
-> ⚠️ **Step 3 does not currently rescue a browse-committed tag.** `RawBrowseCommitMapper`'s
-> MTConnect branch emits a whole `MTConnectTagConfigModel`, whose `ToJson()` always writes
-> `dataType` from a field defaulting to `String` — a non-blank authored type, so step 1 wins
-> and step 3 is never consulted. The raw tag's OPC UA `DataType` meanwhile *is* taken from the
-> browsed leaf's inferred type (`RawBrowseCommitMapper.MapLeaf` → `MapDataType`), so a browsed
-> `SAMPLE` lands as a `Double` node whose driver coerces the observation to text. Fix belongs in
-> the commit mapper (forward the leaf's `DriverDataType` into the model, as the AbCip / TwinCAT /
-> FOCAS branches already do). Recorded as `Driver.MTConnect-003` in
-> [`code-reviews/Driver.MTConnect/findings.md`](../../code-reviews/Driver.MTConnect/findings.md).
+> **A browse-committed tag resolves at step 1, carrying the step-3 answer.** `RawBrowseCommitMapper`'s
+> MTConnect branch emits a whole `MTConnectTagConfigModel`, whose `ToJson()` always writes `dataType`
+> — so a committed blob always states a non-blank type and step 1 always wins. Since Gitea **#560**
+> that stated type is the **browsed leaf's own inferred `DriverDataType`**, the very value step 3
+> would compute, forwarded by `MapLeaf` into `BuildTagConfig` exactly as the AbCip / TwinCAT / FOCAS
+> branches forward their browsed native type (Gitea #536). It therefore agrees by construction with
+> the raw tag row's OPC UA `DataType`, which `MapLeaf` → `MapDataType` takes from the same inference.
+>
+> Before #560 the branch stamped the model's `String` default instead, so a browsed `SAMPLE` landed
+> as a `Double` node whose driver coerced the observation to text — recorded as `Driver.MTConnect-003`
+> in [`code-reviews/Driver.MTConnect/findings.md`](../../code-reviews/Driver.MTConnect/findings.md).
+> A leaf the browser reports **no** type for still commits `String`, and a leaf legitimately inferred
+> as `String` (an `EVENT` item) commits `String` too — in both cases the type the driver would have
+> reached anyway.
+>
+> **Step 3 remains the rescue for a blob that states no type at all** — hand-authored, CSV-imported,
+> or API-posted `RawTags[]` entries carrying only an id, which is the shape it was written for.
 
 ### Quality mapping