Schedule-based thresholds for array size checks.

[lemald]

Asana ticket: 🔮 Build out a way to measure RTR uptime

Note that I used Copilot for the initial implementation, though I read all the code over and modified it in places to be more idiomatic and readable.

To make our alerting and reliability metrics more accurate, we want to be able to dynamically assess our realtime data relative to the level of scheduled service, rather than relative to absolute thresholds. My changes to the README explain the new feature and how to configure it in more detail.

Some notes on how I came up with 0.05 as the multiplier: given that we currently have a shutdown of part of the Orange Line going on, I opted to look at the schedule data there. Grabbing all schedules for route Orange and filtering out shuttle bus stop times gave me the following:

❯ curl "https://api-v3.mbta.com/schedules?filter\[route\]=Orange&filter\[date\]=2026-08-26&filter\[min_time\]=11:00&filter\[max_time\]=13:00" | jq ".data[].relationships.route.data.id" | grep Orange | wc -l
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  427k  100  427k    0     0   854k      0 --:--:-- --:--:-- --:--:--  855k
     388

Meanwhile, querying the /predictions endpoint for route Orange returned a total of 39 predictions. I wanted to give about a factor of 2 for headroom, and 388 is almost exactly 10 times 39, so 1/10 divided by 2 for the headroom gives a ratio of 0.05. For a non-diversion example I looked at the current situation with light rail: during a representative 2-hour window there were 3000 stop times in the schedule, for a threshold of 150 predictions. In reality, we were producing 1078 predictions, showing that in some situations this is actually a very conservative threshold.

[npatel-mbta]

I aslo used co-pilot to review the code, and the few minor issues it raised, I reviewed and think they don't really apply.