docs: fix spellcheck for node status compression docs

Adds the compression vocabulary to .spelling, moves timing units into
the benchmark table header so cells are bare numbers, and relocates the
internal benchmark design spec out of docs/ to live with the harness.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: isubasinghe <isitha@pipekit.io>

Author: isubasinghe

.cspell.json

@@ -85,6 +85,7 @@
     "wftmpl",
     "workflowkey",
     "workflowtemplate",
-    "workflowtemplates"
+    "workflowtemplates",
+    "zstd"
   ]
 }

docs/offloading-large-workflows.md

@@ -19,16 +19,16 @@ Levels are algorithm-specific and default to each library's own default: `gzip`
 
 For context, measurements on synthetic node statuses (sizes are relative to the gzip default, compression times are for ~1MiB and ~10MiB of node status JSON):
 
-| Algorithm | Level       | Size vs gzip | Compress 1MiB | Compress 10MiB |
-|-----------|-------------|--------------|---------------|----------------|
-| `gzip`    | 6 (default) | 100%         | 5ms           | 43ms           |
-| `zstd`    | 2 (default) | 88%          | 6ms           | 49ms           |
-| `zstd`    | 3           | 82%          | 6ms           | 58ms           |
-| `brotli`  | 6 (default) | 72%          | 11ms          | 129ms          |
-| `brotli`  | 9           | 67%          | 24ms          | 232ms          |
-| `brotli`  | 11          | 59%          | 1.7s          | 18.3s          |
-
-Decompression speed is roughly equal for all three algorithms (~9ms per 1MiB of JSON). Higher levels than those shown buy little: brotli 11 compresses best but is ~80× slower than brotli 9, which matters because the controller re-compresses the status on every update of a large workflow. `zstd` 3 and `brotli` 9 are good choices when smaller statuses are worth slightly more controller CPU; they raise the effective node-count ceiling before offloading is required by ~20% and ~50% respectively.
+| Algorithm | Level       | Size vs gzip | Compress 1MiB (ms) | Compress 10MiB (ms) |
+|-----------|-------------|--------------|--------------------|---------------------|
+| `gzip`    | 6 (default) | 100%         | 5                  | 43                  |
+| `zstd`    | 2 (default) | 88%          | 6                  | 49                  |
+| `zstd`    | 3           | 82%          | 6                  | 58                  |
+| `brotli`  | 6 (default) | 72%          | 11                 | 129                 |
+| `brotli`  | 9           | 67%          | 24                 | 232                 |
+| `brotli`  | 11          | 59%          | 1700               | 18300               |
+
+Decompression speed is roughly equal for all three algorithms (about 9 milliseconds per MiB of JSON). Higher levels than those shown buy little: brotli 11 compresses best but is about 80 times slower than brotli 9, which matters because the controller re-compresses the status on every update of a large workflow. `zstd` 3 and `brotli` 9 are good choices when smaller statuses are worth slightly more controller CPU; they raise the effective node-count ceiling before offloading is required by roughly 20% and 50% respectively.
 
 These numbers are from synthetic data; real workflows may compress differently.