feat(mtconnect): one agent client per driver — a second /raw Device is a deploy error (#628)

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

docs/drivers/MTConnect.md

@@ -410,14 +410,24 @@ for anything beyond values-and-conditions.
    `GetHostStatuses()` fresh, and the result rides `DriverHealthChanged` to
    the AdminUI `/hosts` page (no SQL; the `DriverHostStatus` table was
    dropped). See `docs/Telemetry.md`.
-2. **`RawTagEntry.DeviceName` is accepted on the wire shape but ignored for
-   routing.** One driver instance owns exactly one Agent client scoped by
-   `MTConnectDriverOptions.DeviceName` (the top-level config key); the
-   per-tag `RawTagEntry.DeviceName` field the v3 raw-tag identity carries is
-   never read by the driver. Two `/raw` Devices authored under one MTConnect
-   driver instance both resolve to the same one Agent connection. Real
-   per-device routing (a client per device) would be a design change, not a
-   bug fix.
+2. **One MTConnect driver instance = one Agent client = at most one `/raw`
+   Device (#628, decision (b)).** The driver never reads
+   `RawTagEntry.DeviceName`; every raw tag binds through the single Agent client
+   scoped by `MTConnectDriverOptions.DeviceName`. The v3 raw tree always has a
+   Device level (a new driver auto-creates `Device1`), and that single-Device
+   layout is the normal, valid shape — its `DeviceConfig` is merged up into the
+   driver config by `DriverDeviceConfigMerger` (this is how the endpoint lands).
+   With **two or more** Devices under one MTConnect driver there is no merge-up
+   and no routing, so which Device supplies the endpoint is ambiguous. That is
+   now a **deploy-time `DraftValidator` error** (`MTConnectMultipleDevices`),
+   and the AdminUI refuses to *create* the second Device
+   (`RawTreeService.CreateDeviceAsync`, same message): "MTConnect binds all tags
+   through one agent client per driver instance; author one MTConnect driver per
+   agent device." Option (a), a client per Device, was rejected as a design
+   change with no demand. A multi-device Agent is served by several driver
+   instances, each with its own `DeviceName` scope. The driver's init-time
+   Warning for differing `RawTagEntry.DeviceName` values stays as defence in
+   depth for configs that predate the rule.
 
    **The write path is the one place a device name is resolved per DataItem**,
    and it does not use `RawTagEntry.DeviceName` either: it reads the owning
@@ -426,11 +436,6 @@ for anything beyond values-and-conditions.
    So `MTConnectDriverOptions.DeviceName` does double duty — request scope for
    reads/browse, fallback write target for writes.
 
-   **It is no longer silent (#613).** When the instance's raw tags carry two or
-   more distinct non-blank `RawTagEntry.DeviceName` values, driver init logs one
-   Warning naming them and the driver-level scope they collapse into. A single
-   value is not reported (it is just the `/raw` Device's own name). Real
-   per-device routing remains deferred.
 3. **Authoring only *warns* when a declared coercion type cannot hold the
    inferred one (#613).** The AdminUI tag editor (`MTConnectTagConfigModel.Warnings()`)
    compares the declared type with `MTConnectDataTypeInference` over the