Correct the memory figures and record the optimization results

The 241 MB RssAnon here is a decode-only number; the full pipeline peaks at 645 MB
warm, and the encoder's activations (+399 MB per 10 s window) are the largest
single consumer. End-to-end RTF on a Boox Tab Mini C went 6.28 -> 2.24 with the
transcript byte-identical throughout.

README.md

@@ -61,6 +61,45 @@ worst case for int8 SIMD. Back to back against the ggml build of the same model:
 Parity on speed at **half the unevictable memory**, which is the figure that
 decides whether an Android app survives memory pressure.
 
+Those memory figures are **decode only**. Through the full pipeline on Android,
+peak RssAnon is 906 MB: 173 MB of runtime/harness baseline, +55 MB compiling the
+encoder, +231 MB compiling the head, +46 MB for the decoder graphs and their
+330 MB of weights (fully zero-copy — 330.1 MB mmap'd, 0.0 MB copied), and
+**+399 MB of encoder activations**. The front end, not the BitNet decoder,
+dominates memory as well as time.
+
+Note also that XNNPACK's `weight_cache_file_path` fails **silently** if the path
+is not writable — no error, no warning, weights packed into anonymous memory
+instead, and peak RssAnon goes 906 MB to 1552 MB. Check the file exists after
+compiling.
+
+End to end through an Android app, 60 s of English in 10 s windows, every pair
+measured back to back on one device:
+
+| | RTF | wall |
+|---|---:|---:|
+| first working version | 6.28 | 377 s |
+| + big-core pinning before graph compile | 4.95 | 297 s |
+| + idle GEMM workers park instead of spinning | 3.42 | 205 s |
+| + wide encoder mask, batched prompt remainder | 3.23 | 194 s |
+| + chat-prefix KV reused across windows | 2.93 | 176 s |
+| + pause-snapped windows and a silence gate | **2.24** | **134 s** |
+
+**2.8x, transcript byte-identical at every step.** Only the last row processes
+less audio; the rest is the same work done properly.
+
+Per 10 s window the budget is encode 14.6 s, prefill 10.3 s, decode 7.7 s. The
+audio front end — **not** the BitNet part — is the largest single cost. Dropping
+one of its two tokenizer encoders would halve it and does not work: the acoustic
+and semantic branches are nearly orthogonal (cos 0.0435) and comparable in
+magnitude, so each carries a large share of the summed features the decoder was
+trained on.
+
+BitNet shrinks the decoder's weights 4x, but on an ARMv8.0 core with no dotprod
+the ternary kernel is compute-bound, so that reduction buys memory rather than
+speed. Decode runs 212-249 ms/token against a ~124 ms floor set by streaming
+328 MB of 2-bit weights; the LM head is only 42-46 ms/token of it.
+
 ## Fidelity
 
 | stage | vs reference | note |
@@ -77,6 +116,10 @@ per-channel scales beat the single per-tensor scale I8_S uses.
 
 * The encoder window is **fixed at 10 s**; longer audio must be windowed by the
   caller. Convolutions are causal, so a window needs left context and no lookahead.
+  Widening it is not the free win it looks like: 30 s windows cut prompt tokens 25%
+  and the encoder is linear in window length, but its activations are not free —
+  peak RssAnon went 937 MB to 1739 MB and a 3.7 GB device killed the process
+  mid-decode.
 * The decoder graphs are **context-specific** — a ctx=128 prefill cannot be paired
   with a ctx=512 decode.
 * The **chat template is mandatory**. Feeding audio features without the surrounding