Harden static report startup ordering: receiver before RptEna/GI

[masarray]

Scope

This is a lifecycle-hardening change on top of PR #111's exact ARSAS-pinned engine line. A deeper audit of the current MmsReceiveRouter shows that InformationReport PDUs are queued independently of persistent-monitor registration, so late monitor registration is not proven to be the primary cause of the current ARSAS Static DataSet physical failure. The primary physical fix remains in ARSAS PR #256 (RCB-backed selection, SCL authority, indexed-family resolution, and live RCB choice).

Even so, the intended reporting contract documented by the subscription planner is receiver-first: install the report consumer before enabling an RCB and requesting GI. This PR makes that lifecycle ordering explicit for StaticDataSet activation without changing dynamic reporting.

Changes

• Add a StaticDataSet-only receiver-first activation path.
• Capture static RCB/DataSet evidence first, then reserve URCB if applicable.
• Construct and register the persistent monitor before RptEna=true.
• Request GI=true only after the receiver is registered and RptEna is accepted.
• On failed/exception/cancelled startup, keep the receiver registered while best-effort disabling RptEna, release URCB reservation when applicable, then unregister/drain the failed monitor.
• Never Define/Delete/rebind a DataSet in this static path.
• Route non-dynamic calls from StartPersistentReportMonitorWithAttemptEvidenceAsync through the receiver-first path; dynamic activation retains the existing mutation/rollback implementation.

Regression contract

Source-order tests guard RegisterPersistentReportMonitor -> RptEna=true -> GI=true, failed-start RptEna=false -> unregister, and absence of dynamic DataSet mutation from the static activation file.

Integration policy

Keep this draft and do not pin it into the next physical ARSAS candidate until the narrower ARSAS RCB-selection fix is validated. The receive router already retains InformationReports queued during confirmed MMS operations, so this PR is robustness/contract alignment rather than a claimed root-cause fix.