Advance skipped steps in a loop instead of recursing

[theluckystrike]

Fixes #964

update_user_location advanced through skipped steps by calling itself once per step (the "speed run" from #715). One update on a long route nested hundreds of frames deep and aborted with a stack overflow. This change keeps the advance logic and runs it in a loop, so the stack depth no longer grows with the number of skipped steps.

What changed

• navigation_controller/mod.rs moves the existing body of update_user_location unchanged into update_user_location_once. It evaluates the current step, advances at most once and returns ControlFlow::Continue when the same location needs another pass.
• update_user_location loops on that result instead of recursing. Arrival handling, waypoint trimming, deviation checks and the condition state reset are untouched.
• The moved body keeps its indentation, so the diff of that code is the return values only (+35/-9 outside the test).

Test

test_speed_run_skipping_many_steps_uses_bounded_stack follows the recipe from the issue. It builds a 1,000 step route, starts at step 0 and sends one location on step 800 on a thread with a 256 KiB stack. It asserts that step 800 becomes current.

On main plus the test, the test aborts the process.

$ cargo test -p ferrostar --lib test_speed_run_skipping_many_steps_uses_bounded_stack
thread 'speed-run-stack' has overflowed its stack
fatal runtime error: stack overflow, aborting
(signal: 6, SIGABRT: process abort signal)

Under nextest the abort fails only that test (113 passed, 1 failed).

End to end

I ran the issue's recipe through the public API in a throwaway integration test that isn't part of the PR. It uses create_navigator with step_advance_distance_from_step(35, 20, WhileOnRoute) and StaticThreshold { 20, 30.0 } on a 1,000 step route of about 205 km. It calls get_initial_state at the route start and then one update_user_location on step 500 and on step 990.

Each update runs on a 512 KiB thread, the iOS default for secondary threads. On main both debug and release builds overflow the stack and abort. With this change the update returns with step 500 (and step 990) current, and a release build takes 255 ms and 416 ms for those two updates.

To confirm the loop changes nothing else, the same test on a large stack dumped 27 states from 9 jump targets (steps 0, 1, 2, 3, 50, 200, 997, 998 and 999, each followed by two updates at the route end). The dumps from main and from this branch are byte identical.

The per step copying of the remaining steps that the issue also describes is unchanged. The release timings above come from it. Skipping several steps in one pass is a separate design decision and stays out of this PR.

Checks

• cargo test -p ferrostar --lib test_speed_run_skipping_many_steps_uses_bounded_stack aborts on main and passes here
• cargo test -p ferrostar --lib 111 passed, no snapshot changes
• cargo build --verbose, cargo nextest run --no-fail-fast (114 passed) and cargo test --doc (8 passed) in common/
• cargo fmt --check in common/, and cargo clippy -p ferrostar --all-targets with 104 warnings on main and 104 here
• just check-msrv (cargo hack isn't installed here)