docs(vault): destroy the dead weight — 53 pages and the change diary

The vault was 155 pages / 31,210 lines, most of it measurement ledgers for
payloads that no longer run. A throughput figure for a runtime nobody operates is
not a record: AI moves faster than the vault, so the number is wrong before
anyone reads it, and a wrong number in a runbook gets believed. Per the new
purpose test in `AGENTS.md` → *Documentation Policy*, it is destroyed.

Gone (`.AGENTTRASH/20261019-destruction/`, KILL-LIST.txt is the manifest):
- the `frank-medium` endpoint and its five era pages, `frank-npu`, FastFlowLM,
  the ikllama/kingjones/dealign/frank-redo eras, the ling/swift15/freetoken/ubatch
  campaign pages, qwen3.8 spec-matrix and strix-optimizations, the two
  "Running Qwen3.6 …" pages;
- the whole `Pipeline Parallelism/` folder (no live script passes a pipeline flag)
  and the multi-device/x4-pair/hybrid/offload experiment pages;
- every vLLM page — no vLLM endpoint exists on this fleet;
- `LLM/deployment.md` (`Architecture/Deployment Flow.md` is the test-referenced
  owner) and the external surveys (SGLang, Lemonade, llama.cpp forks/diff,
  self-hosted app census, the TTS survey) that were obsolete by construction;
- `log.md`, 2,380 lines. Git holds the chronology; a causal law belongs to the
  page that owns the thing it governs, never to a diary.

Survivors: 101 pages, 17,542 lines, 0 OKF violations, 0 unresolved links. Eras
tables keep the window, payload, runtime, reason and rollback pointer; the rate
columns are blanked. The live shapes stay verbatim — those numbers are what the
deployer and `models.yml` consume.

serverAppConfigs-docs/LLM/Shared Memory Architecture Dankclaw.md

@@ -85,7 +85,7 @@ Available backends for ROCm:
 
 All seven names exist on current vLLM `main` (`AttentionBackendEnum` in
 `vllm/v1/attention/backends/registry.py` —
-[source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/v1/attention/backends/registry.py),
+[source](https://raw.githubusercontent.com/vllm-project/vllm/main/vllm/v1/attention/backends/registry.py)
 read 2026-10-18), and `--attention-backend`, `--numa-bind`, `--numa-bind-nodes`
 are real `vllm serve` flags (`vllm/engine/arg_utils.py:1098,1171-1176`).
 
@@ -103,7 +103,7 @@ vllm serve model \
 
 - `gpu_memory_utilization`: Set lower (0.8-0.85) to leave room for CPU operations
 - `max_model_len`: Match actual context needs
-- `--swap-space` is retired from current vLLM; the CPU KV-offload knob pair, with the upstream `CacheConfig` verification, is owned by [[RAM CPU Offloading in VLLM]]
+- `--swap-space` is retired from current vLLM; the CPU KV-offload knob pair, with the upstream `CacheConfig` verification, is owned by
 
 ### NUMA Binding
 
@@ -213,7 +213,7 @@ Unified memory limits concurrent requests:
 
 The two "No" rows (Async Output, Multi-step Decoding) were transcribed from a
 vLLM feature-support snapshot and not re-checked against current upstream
-*(unverified 2026-10-18)*.
+- (unverified 2026-10-18)*.
 
 ### Context Length
 
@@ -226,7 +226,7 @@ FP8 quantization depends on GPU architecture:
 - MI300 series supports native FP8
 - Radeon RX 7900 supports FP8 via software emulation
 - Strix Halo (gfx1151) uses **software emulation** for FP8 matmuls — RDNA 3.5 has
-  no FP8 tensor instructions ([FP8-ROCM](https://github.com/wabibito/FP8-ROCM));
+  no FP8 tensor instructions ([FP8-ROCM](https://github.com/wabibito/FP8-ROCM))
   expect memory savings, not full compute speedup. (Conflicting vendor-side
   evidence exists for an FP8/INT8 WMMA path used by FSR4 on RDNA 3.5, so treat
   the matmul claim as the settled half.)
@@ -294,8 +294,3 @@ rocm-smi --showtemperature
 
 ## See Also
 
-- [[VLLM Overview]]
-- [[VLLM Index]]
-- [[RAM CPU Offloading in VLLM]]
-- [[Hybrid CPU GPU Processing Dankserver]]
-- [[Running Qwen3.6 27B FP8 on Dankclaw]]