IrqlFloatStateMismatch: pragma[inline_late] on irqlChangesBetween

The `irqlChangesBetween/2` predicate is the hottest single predicate in
the IFSM query at HEAD (~109 s of CPU and 3.43 M result tuples in the
18-query suite measurement on the WDS sample database, accounting for
roughly a quarter of the IFSM query's total cost).

Without a planner hint, the predicate is materialized as a standalone
relation over every `(FunctionCall, FunctionCall)` pair in the codebase
that satisfies its constraints, and only then intersected with the
~25-row dataflow result set produced by `FloatStateFlow::flow`. With
`pragma[inline_late]` plus the matching `bindingset[saveCall,
restoreCall]`, the body is specialized at the single call site after
the dataflow result has bound both arguments, so the predicate body is
evaluated only on the small set of dataflow-derived pairs.

Validation on the WDS sample database (single-query run, cold cache):
  - SARIF result count for cpp/drivers/irql-float-state-mismatch: 0
    (matches the HEAD baseline of 0; correctness preserved)
  - `irqlChangesBetween` no longer appears as a discrete predicate in
    the evaluator log (it has been fully inlined into its call site)
  - New top single-query predicate: 28.9 s, vs 109 s for the
    standalone `irqlChangesBetween` in the baseline suite measurement

This is a planner-hint change only. The predicate body is byte-for-byte
unchanged, so the set of `(saveCall, restoreCall)` pairs the predicate
admits (and therefore the set of `select` rows the query produces) is
unchanged on every database. The `bindingset` is honest: the only
caller (line 215) binds both arguments via the `FloatStateFlow::flow`
result and the `asIndirectExpr` constraints in the same `where` clause.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: NateD-MSFT

src/drivers/general/queries/IrqlFloatStateMismatch/IrqlFloatStateMismatch.ql

@@ -157,7 +157,23 @@ private int anchorLineForCall(Function f, FunctionCall fc) {
  * still be filtered out by the upstream IRQL filter even when this
  * predicate fires; recovering those will require improvements to
  * the IRQL analysis library itself.
+ *
+ * Performance note: `pragma[inline_late]` lets the planner specialize
+ * this predicate at its call site after the dataflow result has bound
+ * `saveCall` and `restoreCall`. Without it, the body would otherwise
+ * be materialized over every (saveCall, restoreCall) pair in the
+ * codebase that satisfies the constraints (millions of tuples on
+ * large drivers), only to be intersected with a much smaller dataflow
+ * result set afterwards. With it, the body is evaluated only for the
+ * dataflow-derived pairs, turning a codebase-wide enumeration into a
+ * per-pair check. The accompanying `bindingset` records the calling
+ * convention required by `inline_late` (both arguments bound at the
+ * call site, which is satisfied by the `from` clause below).
+ * Semantics are unchanged — both annotations are planner hints, not
+ * logical changes.
  */
+bindingset[saveCall, restoreCall]
+pragma[inline_late]
 predicate irqlChangesBetween(FunctionCall saveCall, FunctionCall restoreCall) {
   // Branch 1: source-line bracketing in a function `f` that anchors
   // both calls (directly enclosing or one-level wrapper / common caller).