chore: organize solution into module folders (Core/Server/Drivers/Client/Tooling)

Group all 69 projects into category subfolders under src/ and tests/ so the
Rider Solution Explorer mirrors the module structure. Folders: Core, Server,
Drivers (with a nested Driver CLIs subfolder), Client, Tooling.

- Move every project folder on disk with git mv (history preserved as renames).
- Recompute relative paths in 57 .csproj files: cross-category ProjectReferences,
  the lib/ HintPath+None refs in Driver.Historian.Wonderware, and the external
  mxaccessgw refs in Driver.Galaxy and its test project.
- Rebuild ZB.MOM.WW.OtOpcUa.slnx with nested solution folders.
- Re-prefix project paths in functional scripts (e2e, compliance, smoke SQL,
  integration, install).

Build green (0 errors); unit tests pass. Docs left for a separate pass.

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

tests/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Modbus.IntegrationTests/Docker/docker-compose.yml

@@ -0,0 +1,100 @@
+# Modbus integration-test fixture — pymodbus simulator.
+#
+# One service per profile. Bring up only the profile a test class needs;
+# they all bind :5020 on the host so can't run concurrently. The compose
+# `profiles:` feature gates which service spins up via `--profile <name>`.
+#
+# Usage:
+#   docker compose --profile standard up
+#   docker compose --profile dl205 up
+#   docker compose --profile mitsubishi up
+#   docker compose --profile s7_1500 up
+services:
+  standard:
+    profiles: ["standard"]
+    build:
+      context: .
+      dockerfile: Dockerfile
+    image: otopcua-pymodbus:3.13.0
+    container_name: otopcua-pymodbus-standard
+    restart: "no"
+    ports:
+      - "5020:5020"
+    command: [
+      "pymodbus.simulator",
+      "--modbus_server", "srv",
+      "--modbus_device",  "dev",
+      "--json_file",      "/fixtures/standard.json"
+    ]
+
+  dl205:
+    profiles: ["dl205"]
+    image: otopcua-pymodbus:3.13.0
+    build:
+      context: .
+      dockerfile: Dockerfile
+    container_name: otopcua-pymodbus-dl205
+    restart: "no"
+    ports:
+      - "5020:5020"
+    command: [
+      "pymodbus.simulator",
+      "--modbus_server", "srv",
+      "--modbus_device",  "dev",
+      "--json_file",      "/fixtures/dl205.json"
+    ]
+
+  mitsubishi:
+    profiles: ["mitsubishi"]
+    image: otopcua-pymodbus:3.13.0
+    build:
+      context: .
+      dockerfile: Dockerfile
+    container_name: otopcua-pymodbus-mitsubishi
+    restart: "no"
+    ports:
+      - "5020:5020"
+    command: [
+      "pymodbus.simulator",
+      "--modbus_server", "srv",
+      "--modbus_device",  "dev",
+      "--json_file",      "/fixtures/mitsubishi.json"
+    ]
+
+  s7_1500:
+    profiles: ["s7_1500"]
+    image: otopcua-pymodbus:3.13.0
+    build:
+      context: .
+      dockerfile: Dockerfile
+    container_name: otopcua-pymodbus-s7_1500
+    restart: "no"
+    ports:
+      - "5020:5020"
+    command: [
+      "pymodbus.simulator",
+      "--modbus_server", "srv",
+      "--modbus_device",  "dev",
+      "--json_file",      "/fixtures/s7_1500.json"
+    ]
+
+  # Exception-injection profile. Runs the standalone pure-stdlib Modbus/TCP
+  # server shipped as exception_injector.py instead of the pymodbus
+  # simulator — pymodbus naturally emits only exception codes 02 + 03, and
+  # this profile extends integration coverage to the other codes the
+  # driver's MapModbusExceptionToStatus table handles (01, 04, 05, 06,
+  # 0A, 0B). Rules are driven by exception_injection.json.
+  exception_injection:
+    profiles: ["exception_injection"]
+    image: otopcua-pymodbus:3.13.0
+    build:
+      context: .
+      dockerfile: Dockerfile
+    container_name: otopcua-modbus-exception-injector
+    restart: "no"
+    ports:
+      - "5020:5020"
+    command: [
+      "python", "/fixtures/exception_injector.py",
+      "--config", "/fixtures/exception_injection.json"
+    ]