docs: point the frank-medium runbook and observability page at the new scrape

The capacity work in this runbook was done with ad-hoc probes; the same signals
now have history in Prometheus, so the page says which series to watch and
admits the honest gap — this stack has no alerting, so a saturated pool shows up
on a graph after the fact rather than paging anyone.

serverAppConfigs-docs/Infrastructure/Observability.md

@@ -76,6 +76,20 @@ The rule is the same as for every other service: the only off-host path is a gua
 | `grafana`, `loki` | `grafana:3000`, `loki:3100` | container names on `dankclaw_default` |
 | `comfyui` | `comfyui:8188` | UI probe, no native exporter |
 | `services` | `192.168.0.143:8081`, `:3005` | SearXNG, OpenWebUI up/down probes |
+| `frank-medium` | `192.168.0.235:7770` | vLLM on Dankserver — 418 `vllm:` series |
+| `frank-large` | `192.168.0.143:7770` | llama.cpp on Dankclaw — `llamacpp:` counters |
+
+The two LLM endpoints were added on 2026-09-16, after a night spent diagnosing
+frank-medium by hand. vLLM exports exactly what that diagnosis needed:
+`vllm:kv_cache_usage_perc` (how full the per-card pool is), 
+`vllm:num_requests_waiting` (queue depth), the request-latency histograms, and
+the prefix-cache counters `vllm:prefix_cache_hits_total` /
+`vllm:prefix_cache_queries_total`, whose rates give the reuse rate that says
+whether a pinned conversation is being served warm or re-prefilled cold. What
+those numbers mean on this hardware is in [[frank-medium-radiance-mxfp4]].
+
+Both are scraped on their LAN addresses, never on the guarded vhosts:
+Prometheus cannot solve an Anubis challenge.
 
 For services without a native exporter, use the Prometheus **blackbox exporter** in probe mode to assert up/down and HTTP latency. The homepage status timer probes the same endpoints from the host.