v0.8.0

• Add getTripSchedules(filters) — display-ready trip schedules with everything pre-computed: seconds since the start of the service day (past-midnight times > 86400 supported), unix epochs computed in the agency's timezone (DST-safe "noon minus 12h" rule, zero-dependency via Intl), realtime delays resolved per the GTFS-RT spec (delay ↔ absolute time cross-computed, arrival ↔ departure borrowed, delay propagated to subsequent stops until the next update, trip-level delay fallback, stop_id-only matching), SKIPPED/NO_DATA/canceled flags, display_epoch (departure, or arrival at the terminus; displayMode: 'arrival' flips it), and stop names joined in. Batched internally — one trip or a whole route's day costs the same five indexed queries.
• Add pure time/realtime helpers (exported, usable without a database): parseGtfsTime, gtfsTimeToEpoch, serviceDayStartEpoch, and resolveRealtime — the resolution engine behind getTripSchedules.
• Update the website demo's stop-times view to getTripSchedules (timezone-correct times, realtime departures with strikethrough schedule, canceled/skipped indicators, no more per-stop queries). Add examples/trip-schedules.ts.
• Breaking: split ScheduleRelationship into TripScheduleRelationship and StopTimeScheduleRelationship. The single enum conflated two protobuf enums with different numeric values: at stop level, SKIPPED is 1 and NO_DATA is 2 per the GTFS-RT spec, but the old enum decoded 1 as ADDED and defined SKIPPED = 4 (a value that never occurs in feeds). StopTimeUpdate.schedule_relationship and StopTimeRealtime.schedule_relationship are now typed as StopTimeScheduleRelationship; trip-level fields as TripScheduleRelationship. ScheduleRelationship remains as a deprecated alias of TripScheduleRelationship.
• Fix: GTFS-RT loader dropped legitimate zero values. delay: 0 (explicitly on time), stop_sequence: 0, uncertainty: 0, bearing: 0, speed: 0, and current_status: INCOMING_AT (0) were coerced to NULL; now preserved.
• Fix: stop time updates identified by stop_id only (without stop_sequence, allowed by the spec) are now stored reliably: the rt_stop_time_updates table no longer has a (trip_id, stop_sequence) primary key and gained a (trip_id, stop_sequence) index instead.