docs: distill the managed skill library into the vault (waves 1-7)

All ~173 managed skills read in full and merged, one polished reference
page per skill-cluster:

- LLM cross-cutting (17 pages): GGUF Compatibility, Llama Cpp Serving
  Sizing, Llama Cpp Multi-Device Splits, PCIe Link and Atomics, RDNA4
  Container Serving, RDNA4 MoE Expert Offload VRAM Budget, vLLM Boot
  Forensics, vLLM Porting and Compile Triage, LLM Bench Windows, LLM
  Performance Diagnosis, Model Swap and Rollback, Tcclaviger Fork Ops,
  Heterogeneous Split Triage, FreeToken Builds + deltas folded into the
  retired runbooks (GLM DFlash2 port laws, Lucebox dual-R9700, R9V
  qualification pipeline, FLM pack registration, ik hybrid envelope,
  frank-medium split rebalance, llama.cpp GGUF preflight, batch-ubatch
  split section, bench-window D-state/stale-read notes, second-endpoint
  bring-up).
- Architecture (3): Stale Signal Audit, Quadlet Lifecycle, Deploy State
  Triage.
- Operations (6 + index): Remote Job Runner, Payload and Disk Reclaim,
  Container Host Reachability, Fleet Ops Playbook, Fleet Audit and
  Posture, SSH and Remote Access.
- Infrastructure: Observability Provisioning + Homepage Status Probes;
  updates to Authentik, Anubis, LAN-DNS (per-client DoH bypass, Porkbun
  zone ops), Swap Configuration, OpenWebUI, Hermes (pre-existing page
  preserved and extended).
- FrankBook-Pro: ARR-Stack filled (API split, schema-first probing,
  auth-posture, auth-config trap); qBittorrent E2E verification.
- Desktop/Agent/Research: Noctalia and Niri, OMP Harness, Agent Docs and
  Edits, Command Center Dotfiles, PICO-8 Asset Standards.
- Indexes: LLM Cross-Cutting References section, Operations/ and Agent/
  index pages, root-index Skill Distillation section, AGENTS.md pointer.
- log.md carries the wave plan.

check-vault-links.py 0 unresolved (185 pages); ./tests/run.sh 366/366.

serverAppConfigs-docs/Dankclaw/OpenWebUI.md

@@ -64,6 +64,49 @@ The Ollama connection is disabled (`ollama.enable=false`).
 > repository. Model swaps, context sizing, and spec tuning happen there. See
 > the [LLM knowledge base](../LLM/index.md).
 
+## Container introspection (DB and backend python)
+
+- Working dir for imports: `/app/backend`; package name `open_webui`
+  (underscore), NOT `openwebui`. `os.environ["WEBUI_SECRET_KEY"]` MUST be set
+  BEFORE importing any `open_webui` module (import-time hard requirement);
+  the secret lives at `/app/backend/.webui_secret_key`.
+- **The `sqlite3` CLI is NOT in the container** — use Python's `sqlite3`
+  module (`podman exec open-webui python3 -c "import sqlite3;
+  conn = sqlite3.connect('/app/backend/data/webui.db'); …"`). For config
+  keys use parameterized LIKE queries (avoids shell quoting).
+- Backend python: `podman exec -w /app/backend open-webui python3 -c "…"` —
+  `Models.get_all_models()` is a coroutine (await it); model objects are
+  pydantic `ModelModel` instances (attribute access, not `.get()`), with NO
+  `status`/`enabled` attribute — use `is_active` from the DB.
+- **API auth for verification:** `create_token` lives in
+  `open_webui.utils.auth` (NOT `open_webui.utils.utils`);
+  `get_verified_user` requires an `id` claim (not just `sub`);
+  `SESSION_SECRET = WEBUI_SECRET_KEY`. Mint an admin token inside the
+  container:
+
+  ```
+  podman exec -i open-webui sh -c 'export WEBUI_SECRET_KEY=$(cat /app/backend/.webui_secret_key); \
+    python -c "from open_webui.utils.auth import create_token; \
+    print(create_token({\"id\":\"<UID>\",\"sub\":\"<UID>\",\"email\":\"…\",\"role\":\"admin\"}))"'
+  ```
+
+  (admin UID from the `user` table).
+
+## Verification battery
+
+1. `GET /api/v1/models/list?limit=100` → returns EXACTLY the intended
+   models. Response key is `items`, not `data`.
+2. `POST /openai/chat/completions` per model with a trivial prompt ("Reply
+   with exactly one word: pong") → each returns content `pong`. Reasoning
+   models need `max_tokens>=100` — the thinking block eats the budget.
+3. A 500 "Server Connection Error" → `podman logs open-webui` for
+   `ClientConnectorError`: a network-reachability problem (host LAN IP vs
+   `host.containers.internal`), not a model problem.
+
+**Durability:** the model table + connections are DB-only (not git-managed);
+a fresh data volume loses them. For reproducibility, add an idempotent
+first-start seed script or document the setup in the service doc.
+
 ## Web search
 
 Chat web search is served by [[SearXNG]] on this host, wired in the quadlet
@@ -147,6 +190,23 @@ The quadlet carries a built-in healthcheck (30s interval, 3 retries, 300s start
 
 `podman ps` shows the container as `unhealthy` if either fails. Probe manually at `http://dankclaw:3005/health`.
 
+## Image generation (ComfyUI)
+
+Image generation rides the local [[ComfyUI]] integration, not the chat
+picker — ComfyUI's models never appear in the chat model picker (that is
+chat LLMs only), so ComfyUI needs its own image-generation connection
+configured in OpenWebUI. ComfyUI itself runs GPU-enabled on Dankclaw and
+serves `:8188`.
+
+Endpoint: `POST /api/images/generations` (image `0.11.x`: upstream moved the
+route to `POST /api/v1/images/generations`; the `comfyui` engine is still
+upstream) with `Authorization: Bearer <token>` and body
+`{"model":"imagegen","prompt":"…","n":1,"size":"1024x1024"}`; the response
+carries base64 image data or a URL.
+
+Failure modes: connection refused ⇒ OpenWebUI or ComfyUI is down; timeouts
+on large sizes ⇒ check ComfyUI resources; 401 ⇒ the token is bad.
+
 ## Retired instances
 
 - The compose `open-webui` service (port 3000) was never run: 3000 is Gitea's HTTP port, so it could not bind.