Don't carry the tangent of a clipped step into the next steps

[etiferrier]

Fixes #772.

Problem. With traced jump_ts, a step clipped to just before a jump is often tiny, but the tangent of its length, d(jump) - d(t0), is O(1). PIDController proposes the next step as prev_dt * factor, so that tangent is scaled up into every later step time, and it compounds jump after jump. With several close jump times, the derivative with respect to them ends up wrong by many orders of magnitude, in forward and reverse mode.

Fix. In ClipStepSizeController.adapt_step_size, right after a step lands on a jump_ts or step_ts time, the proposed next step keeps its value but takes the tangent of the new t0 (_drop_step_tangent). The following step times then move rigidly with the time just landed on.

• The primal is unchanged, bit for bit: the value is stop_gradient(next_t1) + (next_t0 - stop_gradient(next_t0)).
• Tangents are untouched everywhere else, in particular through the shrinking of rejected steps, which test_grad_of_discontinuous_forcing relies on. That's why this isn't prev_dt = lax.stop_gradient(t1 - t0) in PIDController: that also fixes Gradients with respect to traced jump_ts blow up: the tangent of a clipped step grows through the next steps #772, but breaks that test.

Test. test_grad_wrt_close_jump_ts has 7 pulses 0.04 apart, with all 14 edges traced, and runs with and without a step_ts grid. It checks against central finite differences, for RecursiveCheckpointAdjoint, DirectAdjoint and ForwardMode.

	Without step_ts	With step_ts
main	fails: +2.2e14 vs −7.7e-3	fails: +2.5e14 vs −7.7e-3
This PR	passes	passes

The rest of the test suite behaves as on main.

Downstream check. I ran dynamiqs, which passes pulse edges as jump_ts, on 8 production-like quantum-device workloads:

• Forward results and step counts are bit-identical, and speed is unchanged.
• The Jacobian columns with respect to pulse-edge times now match finite differences: e.g. relative error 7.9e45 → 1e-5.