Add "Verify area is clear" prerequisite check to `ConflictHigherPriority` scenario

[shai-karassikov]

Is your feature request related to a problem? Please describe.

When the shared test airspace contains a pre-existing operational intent that the qualifier does not expect (e.g., an orphan OIR left over from a previous run or created by a race condition during a run), scenarios.astm.utm.ConflictHigherPriority ("Nominal planning: conflict with higher priority") does not detect the contamination up front. Instead, the scenario proceeds into its planning steps, where the Control USS correctly rejects the Flight 2 plan because it intersects the stale OIR, and uss_qualifier marks this as a "Successful planning" failure.

Because this scenario is run across many tested/control USS pairings, a single contamination event manifests as dozens of ambiguous "Successful planning" failures distributed across the report, each of which looks like a USS behavioral problem. Diagnosing the actual root cause requires dedicated log analysis across scenarios.

This was observed concretely on 2026-04-16 in a qual-partners transition run against the SDD v2.0.2 baseline (codebase interuss/monitoring/v0.28.0), where a single orphan priority-100 OIR produced ~33 cascading failures across ConflictHigherPriority instances. The full root-cause analysis was shared by the UTMverse team on the UTM Implementation US Technical Committee Slack and cross-posted to utmimplementationus/operations_committee#369.

Describe the solution you'd like

Add a Prerequisites test case at the beginning of ConflictHigherPriority that verifies the test area is clear of operational intents before the scenario begins, analogous to the "Verify area is clear" / "Area is clear of op intents" check that ConflictEqualPriority ("Nominal planning: not permitted conflict with equal priority") already performs.

In the same 2026-04-16 run, ConflictEqualPriority instances failed once per scenario with a clear message — "Area is clear of op intents [3] 1 operational intent found in test area" — that pointed directly at the environment state rather than at any USS's behavior. Mirroring this behavior in ConflictHigherPriority would collapse a multi-scenario cascade of ambiguous failures into a single unambiguous "area not clear" finding, making the root cause immediately obvious to anyone reading the report.

Describe alternatives you've considered

• Relying on PrepareFlightPlanners's clear-area call to prevent contamination from persisting across runs: this works in practice but does not help within a run when an unexpected OIR is introduced mid-flight (as happened in the 2026-04-16 case). A per-scenario prerequisite check is defensive regardless of how the contamination arose.
• Post-hoc log analysis by the reader: feasible but costly (required hours of investigation across multiple parties in the 2026-04-16 case). A built-in check eliminates that cost entirely.

Additional context

• Surfaced in a discussion with @BenjaminPelletier on the UTM Implementation US Technical Committee Slack; he suggested this as a candidate for an InterUSS improvement request.
• Evidence comparison from the same test run:
• ConflictEqualPriority example: scenario index s225 — prerequisite check fires once, scenario-level failure is immediate and diagnostic.
• ConflictHigherPriority example: scenario index s121 (and ~30 similar) — no prerequisite check, cascade of "Successful planning" failures at the Control USS's Flight 2 plan attempt.
• Full sequence view and report.json from that run can be attached if useful.

testreport (4).zip

[BenjaminPelletier]

We should extend this logic (verify area is clear as a prerequisite) to "Validation of operational intents" and "Awareness of relevant operational intents" for the same reason. "Data Validation of GET operational intents by USS" could also benefit, though it is perhaps less practically important there as mock_uss is the first USS to act in that case.

We may also want to consider upgrading the "Area is clear of op intents" check severity to Critical because the rest of the test probably can't proceed if the test area is not clear and uss_qualifier has no way to clear it. That would drastically shorten test runs fouled by an errant OI, but it would be somewhat less future-proof if these test scenarios were incorporated into test suites that were able to test other things even with fouled airspace (for instance, if we altered flight intents on a per-scenario-instance basis as would be necessary to parallelize certain sets of test scenarios). Perhaps we could make an AirspaceClearanceManager that would be used by all test scenarios needing to clear airspace (would probably be retrieved from a factory singleton on the basis of a DSS resource the scenario used). It could be responsible for performing the airspace-clearing operations and clear-airspace verifications, and it could fail fast on all subsequent verifications if it determined a particular area of airspacetime was irrecoverably fouled.