time-travel-robustness at beginning of trips

[traines-source]

As discussed previously in the Transitous channel, time travel is not fixed by nigiri under certain circumstances, e.g. in this DELFI RT feed update from today 18:06 (archive) for trip_id 2716892734:

{
"id":"2716892734",
"trip_update":{"trip":{"trip_id":"2716892734","start_time":"22:11:00","start_date":"20250101","schedule_relationship":0,"route_id":"de:aac:05334|51:aseag_3"},
"stop_time_update":[
{"stop_sequence":2,"arrival":{"delay":-15887},"departure":{"delay":-15887},"stop_id":"de:05334:1177:1:1","schedule_relationship":0},
{"stop_sequence":5,"arrival":{"delay":-15917},"departure":{"delay":-15917},"stop_id":"de:05334:1173:1:1","schedule_relationship":0},
... ]
}

I.e. the stop_time_updates only start at stop_sequence 2, and so nigiri keeps the scheduled times or whatever was set before as rt times for the first two stops, crucially without then ensuring a non-negative travel time to the third stop. This is fixed with this PR.

Note that according to the GTFS-RT spec, if initial stops don't have a stop_time_update, "then the consumer should assume that no real-time information exists for [that stop] at that time, and schedule data from GTFS should be used". AFAICT, the nigiri model does not allow for that, because realtime info can not be removed on a stop-by-stop basis. But I don't think this is a major problem, keeping previous realtime info might actually be helpful in some cases, and this should in theory only occur for stops in the past...