docs: self-hosted runner resource classes, capacity budget and drain-before-maintenance procedure

[Xore]

What

Most CI runs on the single homeserver runner (honeypot-ci), which also runs the whole honeypot fleet and GPU benchmark/training work (#3135). #3304 (buildx cache permissions) and #3303 (lease errors) were both runner-state problems. ci-queue-watch.yml and ci-heartbeat.yml watch the queue, but there's no written contract for how much CPU, RAM and disk a CI job may take, which jobs are "heavy", or how to drain the runner before host maintenance.

Proposal

docs/CI-RUNNER.md (or a section in docs/CI-CD.md):

• The runner's labels, and which workflows target it versus hosted runners (the ci-router.yml logic in plain words).
• Measured peak RSS and disk for the heavy lanes (Rust build, Playwright, container builds).
• Where temp and cache live, and their cleanup (cache-cleanup.yml, scripts/prune-buildx-cache.sh).
• Drain steps: pause the runner service, wait for in-flight jobs, and verify no orphaned build containers.

Sources

• docs/ops/RUNNER_BOX.md

Found by the #3194 OmniRoute ops/CI deep-check (pinned 18bbb101, APIARY main 3dca4457).

[Xore]

Picking this up.

[Xore]

Paused (usage limit). Findings so far:

• docs/CI-CD.md → "GitHub CI runner" already covers routing, install, _work cleanup, scaling, instance count and the buildx cache, so this issue overstated the gap.
• Still missing:
  • a drain-before-maintenance procedure (only a one-line warning exists);
  • any resource limit: all five runner units have MemoryMax=infinity and CPUQuota=infinity on the shared 48-core / 92 GB fleet host.
• The docs say 2 instances since 2026-09-05. Live there are 4 honeypot-ci runners (supermicro, -ci-2..4) plus supermicro-home.
• Units 5–7 are gone, but their /var/lib/github-runners/github-ci-runner-{5,6,7}/ dirs (~11 GB) remain.