fix(sqlserver): record transitions before the claim and the report take X locks

[pdevito3]

Summary

Two SQL Server tests can fail with absorbed deadlocks (error 1205). Both tests pin that count to 0.

• Concurrent_relinquishes_and_claims_never_deadlock failed on CI on main.
• Concurrent_outcome_reports_never_deadlock failed on CI for the first commit of this PR. On main, it fails in 6 runs out of 6 when it runs alone.

The claim and the report took X locks on their jobs first, then wrote the Transition Log. The FK check of the transition INSERT can scan jobs, and the deadlock graphs show that scan wait for S locks on the rows of a concurrent claim or report. Each side holds X locks that the other side scans, so SQL Server kills one side.

The claim and the report now write the Transition Log before the UPDATE, in the same batch:

 claim / report batch
-  UPDATE jobs (X locks)  OUTPUT the rows
-  INSERT transitions     -- FK scan waits on rival X locks
+  INSERT @batch  FROM jobs WITH (UPDLOCK)   -- U locks only; the report applies the Effect-Once fence here
+  INSERT transitions FROM @batch            -- U is compatible with the S of the FK scan
+  UPDATE jobs FROM @batch                   -- X locks come last

The expiry and relinquish paths already obey this order. All batch writers (claim, report, expiry, relinquish) now share one transition INSERT (InsertTransitionsFromBatch) and one prune step (PruneTransitionsAsync). The single-row RecordTransitionAsync paths (enqueue, cancel, requeue, cascades, schedule mint) still do the UPDATE first.

Each path also uses one less round trip:

Budget	Before	After
Claim of 32 jobs	6	5
Report of 32 rows	3	2
Report of 32 rows with job output	35	34

Test changes

• Concurrent_outcome_reports_never_deadlock now runs ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE first. Before, an earlier test in the run could leave a narrow plan in the cache, and the test then passed on any lock order.
• The poison is now one 96-row report, not an expiry sweep. Each writer has its own batch text and its own cached plan, so only a wide report poisons the report plan. The test claims the 96 jobs in passes, because one claim returns at most Bounds.MaxClaimBatch (32) rows. The old poison claimed only 32.
• A_claim_writes_its_transitions_before_it_takes_X_locks and A_report_writes_its_transitions_before_it_takes_X_locks pin the lock order with no race. A rival session holds an S lock on one row of the batch. The store passes it with U, inserts the transitions, then waits at the UPDATE. A dirty read taken during the wait must show all 4 entries.

Evidence

Local SQL Server 2022 container, limited to 2 CPUs.

• Before (main, and the first commit of this PR):

  • Relinquish test: failed.
  • Report test, alone: failed 6 runs out of 6 on main, and 7 out of 8 after the first commit.

• After (f00a23c):

  Run	Result
  Concurrent_outcome_reports_never_deadlock, alone	8 out of 8 passed
  Concurrent_relinquishes_and_claims_never_deadlock, alone (both history policies)	10 out of 10 passed
  SqlServerConcurrentMaintenanceTests (10 tests)	5 out of 5 passed
  All 263 tests in BackWave.SqlServer.Tests	2 out of 2 passed

  The build has 0 warnings.

• After the merge of main (with feat(monitor): add a filtered job count #9 and feat: record why a job went back to Scheduled and show Retrying jobs #10): all 273 tests in BackWave.SqlServer.Tests passed, and SqlServerConcurrentMaintenanceTests passed 3 runs out of 3. The claim OUTPUT now also returns retry_cause.

Merge Danger

Door: two-way

The change is SQL text inside SqlServerJobStore. It has no schema change and no change to the stored data, so a revert puts the old statements back.

Blast Radius: SQL Server claim and report

Only the SQL Server adapter changes. Every claim and every outcome report on SQL Server runs the new batch, so a fault here stops work on SQL Server fleets. The Transition Log entries keep the same content.