[ofloveandhate]

Fixes #508.

max_step_size bounded only the growth of a tracker's step. Each track opened with initial_step_size, whatever max_step_size said. With max_step_size 1e-3 and the default initial_step_size 1/10, the adaptive tracker took 17 steps above the maximum before reaching it: six of 0.1, six of 0.05, then halving down. A caller that lowers max_step_size to cross a stretch of the path in small steps got that stretch crossed in one step. In the cellular decomposition that prompted this, two real branches pass about 5e-4 apart, and the path landed on the wrong one.

A track now opens with Tracker::FirstStepSize(), the smaller of initial_step_size and max_step_size, still limited by |t1 - t0| / min_num_steps as before. The AMP tracker and both fixed-precision trackers use it, and so does Tracker::Setup. With the default settings both are 1/10, so default tracks don't change.

Tests: every_step_is_at_most_the_max_step_size_the_first_included (AMP) checks every step of a track under max_step_size 1/1000. the_first_step_is_at_most_the_max_step_size checks the first step of the double and the multiple-precision fixed trackers, which never grow their step. Both fail without the fix: the AMP case reports 17 steps above the maximum.

No ADR: this is a bug fix with a regression test.

🤖 Generated with Claude Code

[ofloveandhate]

Good to catch this. Found while working on some stuff related to the barth decic, where paths come very near each other and a smaller stepsize prevents path crossings.

[ofloveandhate]

yep, it's correct