mbproxy: initial commit through Phase 9 (TxId multiplexing)

Adds the mbproxy service end-to-end. Phases 00-08 implement the
production-ready single-listener / 1:1-backend transparent Modbus TCP
proxy with bidirectional BCD rewriting for the ~54-PLC DL205/DL260
fleet. Phase 9 replaces the connection layer with a single backend
socket per PLC plus MBAP TxId rewriting, lifting the H2-ECOM100's
4-concurrent-client cap as an operational ceiling.

Phase 9 additions of note:
- PlcMultiplexer + UpstreamPipe + TxIdAllocator + CorrelationMap
- InFlightRequest with IReadOnlyList<InterestedParty> (load-bearing
  for Phase 10 read coalescing — do not collapse to a single field)
- Per-request watchdog: surfaces Modbus exception 0x0B to upstream
  on BackendRequestTimeoutMs, defending against lost responses,
  dead-PLC paths, and pymodbus 3.13.0's concurrent-multiplexed-
  request bug (its ServerRequestHandler.last_pdu state race)
- Status DTO + HTML gain inFlight / maxInFlight / txIdWraps /
  disconnectCascades / queueDepth (Tier 1.6 in docs/kpi.md)

Tests: 263 unit + 38 E2E. Multiplexer correctness under truly
concurrent backend traffic is proved against a stub backend in
PlcMultiplexerTests; MultiplexerE2ETests paces requests so pymodbus
3.13's single-PDU framer stays in known-good mode.

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

mbproxy/src/Mbproxy/Proxy/Multiplexing/InFlightRequest.cs

@@ -0,0 +1,41 @@
+namespace Mbproxy.Proxy.Multiplexing;
+
+/// <summary>
+/// One upstream party interested in a single backend round-trip. Carries the upstream
+/// pipe to deliver the response to AND the original MBAP TxId that the party sent — the
+/// multiplexer must rewrite the response's MBAP TxId back to <see cref="OriginalTxId"/>
+/// before handing the frame to the pipe, so each upstream sees the proxy as transparent.
+///
+/// <para><b>Phase 9 invariant:</b> exactly one <see cref="InterestedParty"/> per
+/// <see cref="InFlightRequest"/>. <b>Phase 10 (read coalescing)</b> reuses this exact
+/// shape to fan-out a single backend response to multiple upstream parties. Do not
+/// collapse this into a single field on <see cref="InFlightRequest"/>.</para>
+/// </summary>
+internal sealed record InterestedParty(UpstreamPipe Pipe, ushort OriginalTxId);
+
+/// <summary>
+/// Per-backend-request correlation record. Stored in <see cref="CorrelationMap"/> keyed
+/// by the proxy-assigned TxId; looked up by the backend reader task to:
+/// <list type="bullet">
+///   <item><description>Restore each interested party's original MBAP TxId before forwarding
+///         the response upstream (transparent multiplexing contract).</description></item>
+///   <item><description>Provide the BCD rewriter with the originating request's
+///         <c>StartAddress</c> / <c>Qty</c> for FC03/FC04 response decoding — the response
+///         PDU itself does not carry the start address.</description></item>
+///   <item><description>Measure backend round-trip time via <see cref="SentAtUtc"/>
+///         (replaces the per-pair stopwatch slot from the 1:1 model).</description></item>
+/// </list>
+///
+/// <para><b>Phase 9:</b> <see cref="InterestedParties"/> always has exactly one element.
+/// The list shape is the load-bearing seam that <b>Phase 10 — read coalescing</b> hooks
+/// into to fan out a single PLC response to multiple upstream clients without further
+/// refactor of the multiplexer's data model. Reviewer note: do <i>not</i> simplify back
+/// to a single <c>UpstreamPipe</c> field.</para>
+/// </summary>
+internal sealed record InFlightRequest(
+    byte UnitId,
+    byte Fc,
+    ushort StartAddress,
+    ushort Qty,
+    IReadOnlyList<InterestedParty> InterestedParties,
+    DateTimeOffset SentAtUtc);