docs: correct M6 TurboKV data — #175 affects every chip, not just M5

[solderzzc]

Docs-only correction of data I published in #173 and #174.

What was wrong

Every M6 --turbo-kv run (the README tables, the TurboKV rows in docs/profiling/m6/, and the numbered-lines "24/24 on M6" in #174) passed --ctx-size. On mlx-swift-lm 460ff81, a set capacity makes the attention layers a RotatingKVCache (Qwen35 makeCache(capacity:)), and Server.swift only sets turboQuantEnabled on KVCacheSimple. So those runs were vanilla.

What's actually true

With TurboKV really active (no --ctx-size, so ctx_size=model and KVCacheSimple), the M6 reproduces #175:

numbered lines (tokens)	--turbo-kv on M6
315 (5,266)	"There are 1,314 lines." ✗
700 (11,811)	"There are 1,000 lines." ✗ (same as the M5)

So #175 is platform-independent. The Mac M5 session traced it to KVCacheSimple eviction bookkeeping from mlx-swift-lm #63: compressedOffset gets reset so attention only sees the hot window, and offset restarts near 256. A fix is on its way separately.

Changes

• README: drop the TurboKV columns from the Gemma 4 and Qwen3.8 M6 tables, with a correction note. Rewrite the --turbo-kv loses context history after 2K tokens (attention sees only the last 256 tokens) #175 known issue as "every chip", and note that --turbo-kv currently does nothing when --ctx-size is set.
• docs/profiling/m6/*.md: keep the raw rows, and add a correction note on top.

The --gpu-layers known-issue line is left alone; the Mac M5 session's --gpu-layers warning PR updates it.

🤖 Generated with Claude Code

[solderzzc]

Reviewed (code-review skill, M5 agent): no issues found. The corrected data matches what we measured on both machines. The #175 known-issue note will be updated again by the submodule bump once SharpAI/mlx-swift-lm#65 merges. Merging.