decompress .json.zstd fetched by getSaveData

AGENTS.md

@@ -38,7 +38,7 @@ SaveParserBackendService  ->  /api/proxy/saveParserBackend/*  ->  backend
 
 - [src/services/SaveParserBackendService.ts](src/services/SaveParserBackendService.ts)
   is the only place that talks to the backend. It exposes `uploadSave`,
-  `getSaveStatus`, `getParsedData` and `getSaveFile` — upload, poll until
+  `getSaveStatus`, `getSaveData` and `getSaveFile` — upload, poll until
   parsing finishes, then fetch the result or the stored save back.
 - [src/app/api/proxy/saveParserBackend/[[...path]]/route.ts](src/app/api/proxy/saveParserBackend/[[...path]]/route.ts)
   forwards every method to the configured backend URL. It exists only to keep
@@ -113,6 +113,13 @@ Three things there are easy to break:
 - **Compression runs in a Web Worker** because it would otherwise block the
   page for seconds on a large save.
 
+`getSaveData` is the deliberate exception: the backend stores parsed save data
+as zstd compressed json, and the service decompresses that response on the main
+thread instead of in the worker. Decompression is cheap and its cost does not
+depend on the level — the whole 87 MB of an EU4 save comes back in 0.27 s at
+level 10, and the parsed json is a fraction of that, so it is a matter of
+milliseconds. A worker round trip would cost more than it saves.
+
 [COMPRESSION.md](COMPRESSION.md) has every zstd level measured on a real save —
 size, time and the memory the encoder and decoder need. Consult it instead of
 measuring again when a device cannot cope with the current level.
@@ -203,6 +210,12 @@ does not replace a full build.
 
 Do not report a change as finished until both commands pass.
 
+### Tests and benchmarks
+
+**Never run a test suite or a benchmark without explicit permission.** Ask
+first and wait for a clear yes, however easy the command looks. Lint and build
+are the exception, and are expected after every change.
+
 ## Version control
 
 This project is managed with **git**.