fix: Ensure there is no subtraction panic via underflow

[chookity-pokk]

In the Python version of ConstrainedReschedule when next_t0q > new_t1q the overlap gives a negative number, which is handled by overlap = max(qreg_overlap, creg_overlap) followed by the if overlap > 0 check.

In Rust these values are u64 so the same subtraction panics on underflow. By using saturating_sub we clamp to 0 so it matches the Python behavior.

Fix #16231.

AI/LLM disclosure

• I didn't use LLM tooling, or only used it privately.
• I used the following tool to help write this PR description:
• I used the following tool to generate or modify code:

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[jakelishman]

Thanks for the PR. This is currently targeting the wrong branch: we need to fix it on main, and then we'll backport it to the 2.4 series, since the fix is eligible. If we merge this, then main won't have it, so the bug would reappear in Qiskit 2.5. It'll probably be easier for you to open a new PR that's branched from main, rather than trying to re-target this one, since it's descended from stable/2.4 already.

Beyond that: can we add a one-sentence release note (reno new --edit fix-underflow-constrained-reschedule), and we'll need to add a regression test to stop this happening again.