バス経路順序ロジック (build_stop_route_mapping) のSQL回帰テスト基盤を整備する

[TinyKitten]

背景

stationapi/src/import.rs の build_stop_route_mapping() は GTFS データから (parent_stop_id, route_id) → stop_sequence のマッピングを生成する関数で、池86 のような多バリアント系統で順序を正しく扱うために PR #1511 / PR #1512 で複数回 SQL を調整した。今後さらに調整が入る可能性が高いが、現状この関数を実 GTFS に近い形で検証する単体テストが存在しない（既存の DB 必須テストは大半が #[ignore] 扱い）。

やりたいこと

build_stop_route_mapping() の挙動を locking するための回帰テスト基盤を整える。最低限、以下のシナリオを fixture でカバーしたい:

1. 多バリアント系統（池86 風）: 同一 route_id に複数 shape_id の trip があり、短縮便・出入庫便が混在するケース
2. canonical_shape 選択: 最長 direction_id=0 shape が正しく選ばれること
3. main trip 選択順序: canonical shape 優先 → direction_id=0 → 最多停留所 → 最長 shape_dist_traveled → trip_id のタイブレーク
4. variant-only 連鎖: メイン系統に乗らない停留所を LAG/LEAD 補間で正しい位置に挿入できること
5. shape_dist_traveled NULL 系統: フォールバックパスの動作

実装メモ

• 実 PostgreSQL を起動する必要があるため、sqlx::test か testcontainers で軽量に立てるのが現実的。
• fixture は gtfs_trips / gtfs_stop_times / gtfs_stops / gtfs_routes / gtfs_shapes に最小データを投入する形。
• テスト名は test_build_stop_route_mapping_ike86_canonical_shape のように意図が分かるものにする。

関連

• PR バス経路 池86などのshape_id跨ぎによる停留所順序の崩れを修正 #1512 のレビューで CodeRabbit が指摘。本 PR の修正コミット自体は最小に保ちたかったため別 issue として起票。
• 関連 issue: バス経路順序: variant補間の再帰深さ上限が固定10でアンカー解決に失敗するケースがある #1513（再帰深さ上限の動的化）