fix: wrap-safe micros() timing so the stepper doesn't freeze every ~71 min

[ZMan88]

Problem

On a long-running device the stepper periodically stops moving — commands are accepted but no STEP pulses come out — and then recovers on its own after a while. It looks like a driver/UART glitch but it's a clock bug.

micros() is a uint32_t that overflows every 2³² µs ≈ 71.6 min. The stepper stores those timestamps in time_t and computes deltas from them:

• Stepper::calculate_speed_ — float dt = (now - last_calculation_) * 1e-6f (accel/decel ramp)
• TMC2209Stepper::loop (PULSES_CONTROL / STEP-DIR) — time_t dt = now - last_step_ (the step gate)

Because time_t is signed and wider than 32-bit, right after a micros() wrap now < last_*_, so the delta goes negative. The dt >= interval gate is then never true and no STEP pulses are emitted until micros() climbs back up to the stored value — a freeze of up to ~71 min that then self-heals. The ramp math is corrupted the same way.

should_step_() already used a uint32_t local and is wrap-safe, but the STEP/DIR path in TMC2209Stepper::loop doesn't go through it, so it never benefited.

Fix

Store last_calculation_ / last_step_ as uint32_t and take the now argument as uint32_t, so the subtraction wraps correctly. This mirrors core esphome/components/stepper, which uses uint32_t for exactly this reason. Minimal, type-level change — no behavioural change except that the wrap no longer freezes stepping.

Testing

• Reproduced on an ESP32-C6 (Seeed XIAO) driving a TMC2209 over UART in STEP/DIR mode: the full command path executed correctly (target set, direction computed) while the position counter stayed frozen; a background monitor caught the self-recovery ~33 min into a wrap window — consistent with the wrap theory and not with heat/UART/register drift.
• Builds clean with ESPHome 2026.5.0 (esphome compile → ESP32-C6 image created).

Files changed: stepper/stepper.{h,cpp}, tmc2209/stepper/tmc2209_stepper.cpp.