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

.spelling

@@ -4,12 +4,14 @@
 100Gi
 100Mi
 100s
+10MiB
 10h
 10s
 120s
 120sec
 1Gi
 1Mi
+1MiB
 1h
 1m
 200Ki
@@ -161,6 +163,7 @@ backport
 backported
 boolean
 booleans
+brotli
 buildkit
 changelog
 codebase
@@ -189,6 +192,8 @@ gitops
 goroutine
 goroutines
 govaluate
+gunzips
+gzip
 gzipped
 i.e.
 idempotence
@@ -294,6 +299,7 @@ v3.6.5
 v3.7
 v3.7.0
 v4.0
+v4.1
 validator
 vendored
 versioned
@@ -305,3 +311,4 @@ webpack-dev-server
 workflow-controller-configmap
 workqueue
 yaml
+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.