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/Infrastructure/Authentik Outpost Reference.md

@@ -23,8 +23,8 @@ read-only `SELECT`s, 2026-10-18). Nine proxy providers, all attached to outpost
 `7e39655b-58d3-4fe6-a80a-513f31051217` ("authentik Embedded Outpost", 9
 members in `authentik_outposts_outpost_providers`), all with
 `internal_host = http://caddy:8017`, all carrying the **same three flow
-UUIDs** (`default-authentication-flow`,
-`default-provider-authorization-implicit-consent`,
+UUIDs** (`default-authentication-flow`
+`default-provider-authorization-implicit-consent`
 `default-provider-invalidation-flow`), and each backed by an Application
 (the `slug` column below):
 
@@ -67,7 +67,7 @@ Two provisioning rules, each verified live by an outage:
    reload** — including hosts whose providers were fine (verified 2026-09-02
    when three providers provisioned without any flows took down every guarded
    vhost after a server restart). Backfill all three flows (copy from pk 1:
-   `default-authentication-flow`,
+   `default-authentication-flow`
    `default-provider-authorization-implicit-consent` (the implicit-consent
    authorization flow, `default-invalidation-flow`) and the retry loop
    recovers on its next 3-second cycle. The silent killer: while the outpost
@@ -94,7 +94,7 @@ implementation diverges from upstream in ways that bit us; all verified live:
   contains `"authorization_code"` (enum value with underscore), the token
   endpoint rejects every exchange with `invalid_request`.
 - **Token endpoint is form-encoded + Basic-auth only.** A JSON body makes
-  `parse_token_request` see no `grant_type` → `unsupported_grant_type`;
+  `parse_token_request` see no `grant_type` → `unsupported_grant_type`
   POST-body client secrets are not accepted — authenticate the confidential
   client with `Authorization: Basic base64(client_id:client_secret)`.
 - **Provider resolution is by `client_id` query param** on the global
@@ -107,7 +107,7 @@ implementation diverges from upstream in ways that bit us; all verified live:
   becomes the *expression source* instead of the context; every call raises a
   swallowed `PropertyMappingExpressionException` and the claim is skipped.
   Scope-grant filtering has the same class of bug: `ScopeMapping` has no
-  provider FK (linkage lives in the `ProviderPropertyMapping` through model),
+  provider FK (linkage lives in the `ProviderPropertyMapping` through model)
   so `filter(provider=...)` always yields an empty queryset and tokens asked
   to carry scopes get zero. Net effect: userinfo/introspection answers with
   `{sub}` only — email/groups/entitlements claims cannot be delivered by this
@@ -156,7 +156,7 @@ Hard-won rules (the first is now contested by the live database):
   and retest.
 - `ak shell` import path for the provider model in 2026.8:
   `from authentik.providers.ldap.models import LDAPProvider`.
-  *(unverified 2026-10-18: importing it outside a configured Django shell fails
+  - (unverified 2026-10-18: importing it outside a configured Django shell fails
   with `ImproperlyConfigured`, and no `ak shell` was driven against the live
   auth service for this check)*
 
@@ -188,13 +188,13 @@ is a `password` field on the `default-user-settings` prompt
 
 Two ORM gotchas: `Flow.stages.add()` fails on this through model
 (`Can't bulk create a multi-table inherited model` — `FlowStageBinding` is
-MTI), so create the `FlowStageBinding` row directly with an explicit `order`;
+MTI), so create the `FlowStageBinding` row directly with an explicit `order`
 and a prompt field is a `Prompt` row linked through `PromptStageField`
 (`prompt_stage` + `prompt`; the order comes from `Prompt.order`).
 
 **A blank password must not set an empty password.** `set_password("")` would
 make the account log in with no password, so a validation policy
-(`default-user-settings-no-empty-password`, bound to the prompt via
+(`default-user-settings-no-empty-password`, bound to the prompt
 `PromptStageValidationPolicy`) denies the form when `prompt_data["password"]`
 is `""` and allows it when set. Verified with the `PolicyEvaluator`
 (empty → deny, set → allow, absent → allow) and end-to-end by driving
@@ -213,7 +213,7 @@ three `*_flow_id` columns; the proxy table is
 `authentik_providers_proxy_proxyprovider` (doubled `proxy`) and its PK column
 really is **`oauth2provider_ptr_id`** (proxy providers inherit the OAuth2
 table in 2026.8), the LDAP table is
-`authentik_providers_ldap_ldapprovider` with PK `provider_ptr_id`;
+`authentik_providers_ldap_ldapprovider` with PK `provider_ptr_id`
 `authentik_core_application` attaches to a provider through `provider_id`
 (its PK is `policybindingmodel_ptr_id`, not `id`), and `authentik_outposts_outpost`
 is keyed by `uuid`. So `Provider.objects.filter(type=…)` raising `FieldError`