Module loop_schedule 

Fixed-dwell timetable for closed-loop topologies. LoopSchedule — fixed-dwell timetable for LineKind::Loop groups.

Where crate::dispatch::LoopSweepDispatch lets each Loop car carry whatever per-car door_open_ticks the config specified (so dwell tracks the rider load at each stop), LoopSchedule overrides every Loop car in the group to a single dwell_ticks value. The resulting timetable is predictable — every car spends the same amount of time at every stop on every lap — which is what people-mover lines, gondolas, and timetabled shuttle services want.

What this PR ships

• Fixed-dwell override applied via pre_dispatch: every Loop car in the group has its door_open_ticks rewritten to the schedule’s dwell_ticks once per pass. Idempotent — the same value is written unconditionally each tick, so re-applying the strategy leaves car state unchanged.
• Round-trips through snapshots and config: builtin_id returns BuiltinStrategy::LoopSchedule and snapshot_config / restore_config carry the two tunable fields.
• The construction-time validator (relaxed from the LoopSweep-only check in PR #816) accepts both LoopSweep and LoopSchedule on Loop groups.

Deferred to a follow-up

The target_headway_ticks field is parsed and serialized but the hold-recovery mechanism that would consume it (extending dwell when a car arrives early relative to the preceding car so the schedule resynchronises) lands in the next PR in this series. Keeping it on the struct now is forward-compatible: snapshots taken today survive the wiring change unchanged.

Bunching under heavy load is therefore a known v1 limitation. With fixed dwell alone, a leading car that picks up an unusually large group can fall behind schedule, and the following car catches up. Hold-recovery prevents that follower-on-leader bunching.

Structs

LoopScheduleDispatch

Dispatch strategy that holds Loop cars to a uniform dwell at every stop.