refactor: (schedule-for-route endpoint) stopTripGroupings direction mapping, stop ordering, and headsign order don't match Java OBA

[Ahmedhossamdev]

Problems

1. Wrong direction ID → group mapping
The handler hardcodes group "0" for GTFS direction_id=0 and "1" for direction_id=1.
The Java convention (already implemented in stops-for-route) sorts direction IDs descending so
the highest becomes group "0":

• GTFS direction_id=1 → group "0"
• GTFS direction_id=0 → group "1"

2. Stop IDs are unordered
stopIds per group is built from a Go map, so order is random on every request.
stops-for-route uses GetOrderedStopIDsForRouteDirection (stops ordered by max stop_sequence
across trips in the direction), which matches Java's output.

3. NULL direction_id not handled
When a trip has direction_id = NULL, all such trips collapse into group "0" via an incorrect
int64 check. stops-for-route detects !trip.DirectionID.Valid and falls back to
GetOrderedStopIDsForTrip.

4. Non-deterministic tripHeadsigns
Headsigns are collected via map iteration so their order varies between requests.

Expected fix

Mirror the processTripGroups logic from stops-for-route for direction grouping and stop
ordering, then extend it to also collect tripIds and tripsWithStopTimes per group.