Task #152 — Modbus coalescing: surface auto-prohibitions through diagnostics

Auto-prohibited ranges (#148) were previously visible only through an
internal AutoProhibitedRangeCount accessor used by tests. Production
operators had no way to see what the planner had learned without pulling
logs or inspecting driver state.

Changes:

- New public record `ModbusAutoProhibition(UnitId, Region, StartAddress,
  EndAddress, LastProbedUtc, BisectionPending)` — operator-facing snapshot
  shape. Lives in the addressing assembly's logical namespace alongside
  the other public types.
- `ModbusDriver.GetAutoProhibitedRanges()` returns
  `IReadOnlyList<ModbusAutoProhibition>` — a copy of the live prohibition
  map. Lock-protected snapshot so consumers don't race with the re-probe
  loop.
- RecordAutoProhibition tracks first-fire vs re-fire via the dictionary
  insert path, leaving a hook to add structured logging once an ILogger
  is plumbed through (currently elided to keep the constructor minimal
  for testability — a future change can wire ILogger and emit a single
  warning per first-fire).

Tests (1 new, additive to the 6 in ModbusCoalescingAutoRecoveryTests):
- GetAutoProhibitedRanges_Surfaces_Operator_Visible_Snapshot — confirms
  the snapshot shape: empty before any failure, populated with correct
  UnitId/Region/Start/End/BisectionPending after a failed coalesced read,
  LastProbedUtc within the recent past.

Docs:
- docs/v2/modbus-addressing.md — new "Coalescing auto-recovery" subsection
  consolidates the #148/#150/#151/#152 surface in one place. Documents
  the diagnostic accessor + flags the in-process consumption pattern
  (Server health endpoints today; Admin UI when an RPC channel exists).

239 + 1 = 240 unit tests green.

Caveat: the Admin UI surfacing (table render, "clear all prohibitions"
button) is intentionally NOT shipped here. Admin can't reach a live
ModbusDriver instance without a driver-diagnostics RPC channel that
doesn't exist yet — that's a larger architectural piece. For now the
data is queryable in-process by the Server's health endpoints; once an
RPC channel lands, Admin can wire the existing GetAutoProhibitedRanges
into a Blazor table without further driver changes.

docs/v2/modbus-addressing.md

@@ -169,6 +169,31 @@ Beyond per-tag addressing, `ModbusDriverOptions` exposes (#139–#143):
   bridge between adjacent register tags. With `MaxReadGap=10`, three tags
   at HR 100/102/110 collapse into one FC03 of quantity 11.
 
+### Coalescing auto-recovery (#148 / #150 / #151 / #152)
+- A coalesced read that fails with a Modbus exception (write-only or
+  protected register mid-block) records the failed range as
+  auto-prohibited. The planner stops re-coalescing across the range; the
+  per-tag fallback path keeps healthy members working in the same scan.
+- **Bisection (#150)**: every re-probe pass narrows multi-register
+  prohibitions by trying the two halves separately. Over log2(span)
+  ticks the prohibition pins at the actual offending register(s);
+  intermediate halves that succeed get cleared.
+- **Periodic re-probe (#151)**: opt in via
+  `AutoProhibitReprobeInterval` (TimeSpan?). Default null = disabled
+  (prohibitions persist for the driver lifetime; clear on
+  `ReinitializeAsync`).
+- **Per-tag escape hatch**: `CoalesceProhibited` (bool, default false)
+  on `ModbusTagDefinition`. The planner reads such tags in isolation
+  regardless of `MaxReadGap`. Use for known-bad addresses you want to
+  exclude from the auto-discovery loop.
+- **Diagnostics (#152)**: `ModbusDriver.GetAutoProhibitedRanges()`
+  returns a snapshot of every active prohibition as
+  `ModbusAutoProhibition` records (UnitId / Region / StartAddress /
+  EndAddress / LastProbedUtc / BisectionPending). Surface in the
+  driver-diagnostics RPC channel when that wiring lands; for now
+  consumable by in-process callers (Server health endpoints, log
+  aggregation).
+
 ## JSON DTO shape
 
 The factory accepts both the structured form (legacy) and the new