Implement Trip Search API

[jliu1016]

Description

Create the API to allow users to search for train schedules.

Requirements

• Architecture: Follow NestJS patterns: Controllers for request handling, Services for business logic, and Repositories for data access. Use @InjectRepository(EntityName) for MikroORM injection. See Custom Repositories.
• Endpoint: GET /trips/search
• Query Params: origin, destination, date
• Logic: Use GtfsService to query GTFSTrip and GTFSStopTime to return valid start/end times.

Acceptance Criteria

• Returns list of available trips for the date.

---

Disclaimer: This ticket was generated using AI. Please practice caution and consider if information may be outdated.

[BreakableHoodie]

The GTFS-based approach described in this issue is the right call — faster, no API dependency, works offline. A note on the existing partial implementation: trip-schedule.service.ts already implements getTripSchedule(orgStation, destStation, date) for KI↔Union using GTFSTrip and GTFSStopTime. The implementation here should be a generalisation of that existing service, not a from-scratch build. The main change needed is removing the hardcoded station restriction.

On the Metrolinx Schedule/Journey API as an alternative: it offers a trip planner with transfers, but uses Metrolinx-specific "StopCodes" (not GTFS stop_id) which don't have an obvious mapping in our database. It also adds API latency and rate-limit risk to every search. The static GTFS approach is clearly better for this use case.

StopCode note (cross-cutting): several Metrolinx REST API endpoints use a "StopCode" identifier that differs from the GTFS stop_id values stored in our database. If any future feature needs those legacy REST endpoints (Schedule, Stop, Fares), a mapping will need to be built — either by calling GET api/V1/Stop/All and matching on stop name, or by using GTFS-RT endpoints which use standard GTFS IDs. This doesn't affect the trip search implementation, but is worth knowing.