[joelagnel]

Recapture a changed graph at once after it has replayed unchanged, if no
node changes op or starts or stops running a kernel. Keep the initial
warmup, and reset it when graph properties keep changing or a node
changes.

Benchmark results on RTX 5090:

llama-batched-bench -c 131072 -b 2048 -ub 512 -npp 15872 -ntg 512 -npl 8 -ngl 99 -t 4 -tb 4 -fa on -ctk f16 -ctv f16 -kvu -lv 5

Configuration:
- RTX 5090, Windows x64, driver 617.14, CUDA 12.9.
- Qwen3.8-27B Q4_K_M.

+------------------------+------------+-------------------------+------------------+------------------+
|       Workload         | Mean effect|         95% CI          | With patch       | Without patch    |
+------------------------+------------+-------------------------+------------------+------------------+
| llama-batched-bench    |   +1.14%   | +0.44% to +1.84%        | 299.21 tok/s mean| 295.85 tok/s mean|
|                        |            |                         | 299.82 median    | 295.80 median    |
+------------------------+------------+-------------------------+------------------+------------------+

I also tested thoroughly on RTXspark (NVIDIA N1X) and DGX Spark (GB10)
and for those, no statistically significant improvement or regression
was detected.

[gaugarg-nv]

This PR is going to be incompatible with #22155 that can cause cudaDeviceSynchronize on a shape change.

If you capture graph in such a case, it will break.

[joelagnel]

@gaugarg-nv, thanks a lot, I agree there is a chance of cudaDeviceSynchronize during capture. I updated the PR to exclude legacy CUDA pool case. Tested on my devices.

[gaugarg-nv]

@joelagnel Can you test dflash2 and MTP (chose draft length of 7 and 15 for both) with some p_min value that would change the batch size during target verification?

In these cases, I would expect cudaGraphExecUpdate to fail more frequently and that can cause perf regression with this change.