Task #253 follow-up — driver-side e2e debug: port fixes + HR[200] scratch register

Ran the driver CLIs against the live docker-compose fixtures to debug
what actually works. Two real bugs surfaced:

1. `e2e-config.sample.json` pointed at the wrong simulator ports:
     - Modbus: 5502 → **5020** (pymodbus compose binding)
     - S7:      102 → **1102** (python-snap7, non-priv port)
     - AbCip:   no port → now explicit **:44818**
   `test-modbus.ps1` default `-ModbusHost` also shipped with 5502;
   fixed to 5020.

2. Modbus loopback was off-by-2 because pymodbus `standard.json` makes
   HR[100] an auto-increment register (value ticks on every poll).
   Switched `test-modbus.ps1` to **HR[200]** (scratch range in the
   profile) + updated sample config `bridgeNodeId` to match.

Also fixed the AbCip probe: `-t @raw_cpu_type` was rejected by the
driver's TagPath parser ("malformed TagPath"). Probe now uses the
user-supplied `-TagPath` for every family. Works against both
ab_server and real controllers.

Verified driver-side against live containers:
 - Modbus  5020:  probe ✓, HR[200] write+read round-trip ✓
 - AB CIP  44818: probe ✓, TestDINT write+read round-trip ✓
 - S7      1102:  probe ✓, DB1.DBW0 write+read round-trip ✓

## Known blocker (stages 3-5)

README now flags — and the 4 child issues under umbrella #209 track —
that `src/ZB.MOM.WW.OtOpcUa.Server/Program.cs:98-104` only registers
Galaxy + FOCAS driver factories. `DriverInstanceBootstrapper` silently
skips any `DriverType` without a registered factory, so stages 3-5
(anything crossing the OPC UA server) can't work today even with a
perfect Config DB seed. Issues #210-213 scope the factory + seed SQL
work per driver.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

scripts/e2e/README.md

@@ -51,6 +51,30 @@ knows. Those NodeIds live in `e2e-config.json` (see below). The
 published tag must be **writable** — stages 4 + 5 will fail against a
 read-only tag.
 
+## Status
+
+Stages 1 + 2 (driver-side probe + loopback) are verified end-to-end
+against the pymodbus / ab_server / python-snap7 fixtures. Stages 3-5
+(anything crossing the OtOpcUa server) are **blocked** on server-side
+driver factory wiring:
+
+- `src/ZB.MOM.WW.OtOpcUa.Server/Program.cs` only registers Galaxy +
+  FOCAS factories. `DriverInstanceBootstrapper` skips any `DriverType`
+  without a registered factory — so Modbus / AB CIP / AB Legacy / S7 /
+  TwinCAT rows in the Config DB are silently no-op'd even when the seed
+  is perfect.
+- No Config DB seed script exists for non-Galaxy drivers; Admin UI is
+  currently the only path to author one.
+
+Tracking: **#209** (umbrella) → #210 (Modbus), #211 (AB CIP), #212 (S7),
+#213 (AB Legacy, also hardware-gated — #222). Each child issue lists
+the factory class to write + the seed SQL shape + the verification
+command.
+
+Until those ship, stages 3-5 will fail with "read failed" (nothing
+published at that NodeId) and `[FAIL]` the suite even on a running
+server.
+
 ## Prereqs
 
 1. **OtOpcUa server** running on `opc.tcp://localhost:4840` (or pass