Cache does not invalidate when data changes

Describe the bug
The cache for time series data does not invalidate when the data within the request changes. Affects at least GET and POST /timeseries (though quite possibly other endpoints as well). Tested in 2026.01.23-develop.

Expected behavior
If I make a GET /timeseries request for data on Jan 5-7 and subsequently make a POST /timeseries request to add data on Jan 6, a subsequent GET /timeseries request for the same data should invalidate the cache and respond with current data.

To Reproduce
Steps to reproduce the behavior:

(Within a relatively short timeframe to avoid cache becoming stale, and assuming that specific cache-control headers are not included)

1. Make a GET /timeseries request for a specific time window
2. Make a POST /timeseries request to edit data for the same time series within the same time window
3. Make the original GET /timeseries request again
4. Note that the response has not changed from the original request

CDA Version (please complete the following information):

• Version 2026.01.23-develop

Additional context
When known to potentially cause issues, the cache can sometimes be disabled by including custom Cache-Control headers with the request. However, this can be unreliable due to headers being blocked by CORS settings in some environments (e.g. CWBI). The ideal solution would be to incorporate "smarter" cache handling.

Start by tracing the cache handling for GET and POST /timeseries and reproduce the documented request sequence within the cache lifetime. Done means a GET for a time window returns updated data after a POST changes data in that window, without relying on custom Cache-Control headers.