P5 #144: event-driven persistent report receive path

[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.