Restore OPTION(RECOMPILE) to plan_correction's payload: #2760 removed it on an unverified compile-cost claim #2766

PR #2762 (issue #2760) removed OPTION(RECOMPILE) from both statements in PlanCorrectionCollector.PayloadBodyText. The justification was that ~4,237ms of avg CPU observed on multi-45/Demo was compile cost being paid per database, per server, every cycle.

That attribution was never verified

It was inferred from a telemetry signature (high CPU against 381 logical reads and 18 rows), not measured. Nothing ever isolated compile time from execution time.

The actual cost was the live Query Store catalog-view joins in the final SELECT — which PR #2765 then replaced with staged temps, completing the sp_QuickieStore pattern. Staging fixed it. Removing RECOMPILE never addressed it.

Measured compile cost, post-#2765

SET STATISTICS TIME ON against SQL Server 2025, current dev payload text:

Clean, no errors. Measured on a Rosetta-emulated container, so 84ms is a ceiling — real hardware compiles faster.

Why RECOMPILE belongs here

Plan cache hygiene, not performance. This body runs once per database, per server, every cycle. Caching a plan for each of those accumulates cache bulk across the fleet for plans nobody reuses. RECOMPILE keeps them out of cache entirely, and at ~84ms total that costs effectively nothing.

Fix

Restore OPTION(RECOMPILE) to the two statements #2762 removed it from, in the post-#2765 query shape. Everything #2765 introduced (the four #pm_plan_correction_* staging temps, the EXISTS-gated SELECT INTOs, the final SELECT joining temps rather than catalog views) stays exactly as-is. Rewrite the doc comment to state the plan-cache-hygiene reason and correct the record, and replace the PayloadBody_DoesNotCarryRecompile test with one pinning that RECOMPILE is present, so this does not get removed again to "save" compile time.