[masarray]

Stacked performance slice for #144, based on PR #146. This keeps the optimization isolated from PR #147's targeted-availability ownership and from active ARSAS integration/packaging lanes.

Goal

Remove the last artificial 25 ms application polling loop from the normal persistent reporting hot path when the association-owned MMS receive pump is running.

The receive pump already blocks efficiently on transport I/O. Polling its routed InformationReport queue every 25 ms adds avoidable wakeups, first-report latency and scheduler noise.

Design

• the canonical InformationReport queue remains the single routing authority;
• MmsReceiveRouter adds one binary async availability signal;
• every queued InformationReport raises that signal;
• multiple reports coalesce into one wake because the queue is drained after wake;
• no report payload is duplicated and no second report-routing pipeline is introduced;
• persistent monitor receive waits on the signal instead of Task.Delay(25ms);
• wait duration is bounded by the next legitimate residual-poll deadline or the receive-slice deadline;
• the legacy no-receive-pump compatibility path is intentionally unchanged.

Anti-naive boundaries

• no fixed sleep in the normal receive-pump path;
• no busy loop;
• no per-RCB background thread;
• no broadcast-copy report payloads;
• no traffic-before-reporting dependency;
• no change to RCB activation, GI, static/dynamic planning or canonical model policy;
• no vendor branching.

Regression

Adds router-level tests proving:

• pre-queued report returns immediately;
• a future InformationReport wakes an awaiting consumer;
• no-report case respects bounded timeout.

Expected runtime effect

Normal path becomes event-driven:

receive pump blocks on transport
        ↓
InformationReport arrives
        ↓
router queues + signals
        ↓
persistent monitor wakes immediately
        ↓
canonical queue drains and routes

instead of:

Task.Delay(25ms)
→ check queue
→ Task.Delay(25ms)
→ check queue
...

This is a latency/CPU optimization only; functional reporting semantics remain unchanged.

[masarray]

Staging PR reconciliation (2026-10-22): functional scope superseded by newer staging implementation, not Git ancestry and NOT verbatim branch merge. Original SHA 397aa8254ab3eedb81a65702e0dc8db0a3f5186e still has some different source commits, so do not equate this closure with byte-identical whole-branch incorporation.

Evidence: Staging MmsReceiveRouter.WaitForInformationReportAsync and MmsPersistentReportMonitor's awaited signal-driven receive are present; staged regression tests explicitly cover prequeued wake, future wake without polling, coalesced burst, bounded no-report timeout and terminal fault.

Staging SHA 44ac7554f43f2ba06763f3895242cb569b2e6a1c passed Windows synthetic-merge CI #39782663272, 1,262/1,262 tests, 0 warnings/errors. Closing outdated stacked PR to leave one release lane: staging→main #192, still DRAFT with FAT/consumer gates. Source branch remains available; reopen if later field evidence reveals a missing behavior. No ARSAS repin or mainline merge.