[FEATURE] Implement server-side caching for Metrolinx real-time API calls

[BreakableHoodie]

🚀 Feature Description

When real-time Metrolinx API calls are added (trip updates, service alerts, fleet consist), responses must be cached server-side to avoid per-user-request calls to the Metrolinx API.

💡 Problem Statement

The Metrolinx API ToS (§6) reserves the right to impose rate limits and requires that apps not attempt to circumvent them. Without server-side caching, every user action that requires real-time data (e.g. loading a trip, checking alerts, viewing a train consist) would result in a direct Metrolinx API call, which will quickly hit rate limits at any meaningful scale.

The static GTFS download already uses ETag/If-Modified-Since correctly — the same discipline needs to be applied to real-time feeds.

🎯 Proposed Solution

Implement a caching layer for all Metrolinx real-time API responses before any real-time integration goes live:

• Trip Updates / Alerts: Cache for ~30 seconds (these feeds refresh on a fixed interval)
• Fleet Consist: Cache for the duration of a trip service day (consists are stable within a day)
• Cache should be shared across all users (not per-user), since the data is not user-specific

🔄 User Story

As a backend developer, I want real-time Metrolinx data to be cached server-side so that the app stays within API usage limits and remains compliant with the terms of use.

📋 Acceptance Criteria

• Trip update and alert responses are cached server-side with an appropriate TTL
• Fleet consist responses are cached server-side with an appropriate TTL
• Multiple concurrent users requesting the same data result in a single upstream API call
• Cache is invalidated/refreshed appropriately when data is stale

🔗 Related Issues

Depends on the Metrolinx real-time API integration being built. Related to Metrolinx API ToS compliance review.