perf(firms): serve a cached body and gzip instead of serialising per request

/api/firms ran JSON.stringify over the whole fire set for every request and
sent it uncompressed: about 20 MB per 100,000 detections.

The handler now keeps the last body as bytes and reuses it for the same
cache entry and stale flag while the clock stays inside the span over which
the trailing-24 h filter keeps the same detections, so the JSON a request
gets is byte-identical to a fresh serialisation. A client that accepts gzip
gets the body gzipped, compressed once per kept body.

The span ends when the oldest kept acquisition minute turns 24 h old, so
requests minutes apart are still serialised afresh.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

docs/CURRENT-STATE.md

@@ -3297,6 +3297,15 @@ The `get_active_fires` tool reports acquisition times as UTC ISO timestamps,
 including zero-padded hours and minutes; missing or invalid dates and times
 remain `null`, including impossible calendar dates from a custom source.
 
+`/api/firms` keeps its last response body as bytes and reuses it for requests
+that would get the same payload: the same cache entry and `stale` flag, while
+the clock stays inside the span over which the trailing-24-hour filter keeps
+the same detections. That span ends when the oldest kept acquisition minute
+turns 24 hours old, so requests minutes apart are still serialised afresh. A
+client that sends `Accept-Encoding: gzip` gets the body gzipped (compressed
+once per kept body, `Content-Encoding: gzip`); every response carries
+`Vary: Accept-Encoding`. The JSON is unchanged.
+
 The FIRMS proxy records source success after appending its rows. If aggregation
 throws, that source reports failure without a contradictory success entry.
 The existing per-record append continues to support large feeds; sequential