chore: add per-module code review process and tracking infra

Adapts the code-review procedure, folder layout, template, and tooling
from the sibling mxaccessgw repo to lmxopcua.

- REVIEW-PROCESS.md: per-module review workflow — a module is one src/
  or tests/ project (ZB.MOM.WW.OtOpcUa. prefix stripped); 10-category
  checklist; finding IDs/severities/statuses; re-review rules.
- code-reviews/_template/findings.md: per-module findings template.
- code-reviews/regen-readme.py: generates the cross-module README.md
  index from the per-module findings.md files; --check gates staleness
  and consistency.
- code-reviews/test_regen_readme.py: dependency-free generator tests.
- code-reviews/prompt.md: orchestration prompt for clearing the backlog.
- code-reviews/README.md: generated index (no modules reviewed yet).
- scripts/check-code-reviews-readme.ps1: CI / pre-commit check wrapper.

Adapted to this repo: ZB.MOM.WW.OtOpcUa module naming, OtOpcUa
conventions checklist (in-process GalaxyDriver + mxaccessgw,
contained-name vs tag-name, ACL at DriverNodeManager), single .NET
solution build/test commands, and the lmxopcua design docs.

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

code-reviews/prompt.md

@@ -0,0 +1,78 @@
+# Prompt — resolve open code-review findings
+
+Reusable orchestration prompt for clearing the `code-reviews/` backlog. Paste it
+to a fresh agent when you want the remaining findings worked through.
+
+---
+
+Resolve all open code-review findings (every severity), following the workflow
+in `REVIEW-PROCESS.md`.
+
+## Setup
+
+- Read `code-reviews/README.md` for the open findings and `REVIEW-PROCESS.md`
+  for the workflow. Group the open findings by module.
+- A module is one folder under `code-reviews/` — one `src/` project or one
+  `tests/` project, named with the `ZB.MOM.WW.OtOpcUa.` prefix stripped. The
+  module→project mapping is in `REVIEW-PROCESS.md` section 1; the build/test
+  commands are in `CLAUDE.md` ("Build Commands").
+
+## Dispatch — one general-purpose subagent per module, in batches of ~5 modules
+
+Each subagent, for every open finding in its assigned module, must:
+
+- Verify the finding's root cause against the actual source. Do NOT trust the
+  finding text — if it is wrong or misclassified, re-triage it (correct the
+  severity/description in that module's `findings.md`) instead of forcing a fix.
+- Use real TDD: write the regression test FIRST and run it to confirm it fails,
+  THEN implement the root-cause fix, THEN confirm it passes. (Do not use
+  `git stash` — parallel agents would race on the shared stash stack.)
+- The regression test belongs in the reviewed project's own test project — a
+  finding in `src/.../ZB.MOM.WW.OtOpcUa.Driver.Galaxy` gets its test in
+  `tests/.../ZB.MOM.WW.OtOpcUa.Driver.Galaxy.Tests`.
+- Run that module's build and test suite and confirm it is green:
+  - Build + unit-test the affected project, e.g.
+    `dotnet build src/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy/...` and
+    `dotnet test tests/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Galaxy.Tests/...`.
+  - A single test: `dotnet test --filter "FullyQualifiedName~MyClass.MyMethod"`.
+  - `*.IntegrationTests` need their Docker fixture up — bring it up with
+    `lmxopcua-fix up <driver> <profile>` (see `CLAUDE.md` "Docker Workflow").
+    DB-backed `*.Configuration.Tests`, `*.Admin.Tests`, and `*.Server.Tests`
+    need the central SQL Server. If a fixture/service is unavailable, document
+    why the suite was skipped rather than reporting it green.
+  - For a change that crosses project boundaries, build each affected project;
+    a whole-solution check is `dotnet build ZB.MOM.WW.OtOpcUa.slnx`.
+- Update only that module's `code-reviews/<Module>/findings.md`: set each
+  resolved finding's Status to `Resolved` with a Resolution note describing the
+  fix (the orchestrator appends the fixing commit SHA), and update the header
+  "Open findings" count.
+- CONSTRAINTS: edit only the source and test files needed for the assigned
+  module's findings, plus that module's own `findings.md`. Do NOT edit
+  `code-reviews/README.md`. Do NOT commit. Do NOT touch another module's
+  `findings.md`.
+- Report a summary: each finding — root-cause confirmation, the fix, test names,
+  and any re-triage.
+
+Batch so that no two subagents in the same batch write to the same project. In
+particular do not review a `src/` project and its matching `*.Tests` project in
+the same batch — a finding in the source project adds its regression test to
+that test project.
+
+## After each batch returns (orchestrator does this — keep your own context lean)
+
+- Build and test every project the batch touched, using the `CLAUDE.md`
+  commands; confirm clean. For a wide change, `dotnet build ZB.MOM.WW.OtOpcUa.slnx`.
+- Commit per module — one commit per module, message referencing the finding
+  IDs. Record the fixing commit SHA in each finding's Resolution.
+- Regenerate the index: `python code-reviews/regen-readme.py`, then
+  `python code-reviews/regen-readme.py --check` to confirm it is consistent;
+  stage `code-reviews/README.md`. (Use `python` — the bare `python3` alias on
+  this box resolves to the Windows Store stub and fails.) You may stage
+  `README.md` with each module's commit, or commit it once per batch after the
+  script runs.
+- Push.
+
+## Continue
+
+Continue batch by batch until all findings are Resolved or re-triaged. If a
+finding needs a design decision, skip it and surface it rather than guessing.