Overview: show each colony's host and its live stats - CPU, memory, microVMs, disk

[ParallelEntrepreneur]

Goal

The OVERVIEW page (web/src/cockpit/OverviewView.tsx) lists colonies grouped by org but says nothing about the machine they run on or what that machine is doing. Each colony should show its host and that host's live stats — CPU, memory, microVM (MiniKVM) count, disk — plus the other facts an operator needs at a glance.

Evidence

• web/src/cockpit/OverviewView.tsx (main): org card grid at line 71; a colony row renders only a status dot (106), session.issue_title || short (108), repo#issue (109) and a status label (113). No host, no resource figures.
• The API has no host entity. crates/colonizer/src/runtime.rs Runtime (line 39) exposes only platform (linux-x86_64 | darwin-arm64 | other, from telemetry::platform()), kvm {ok, error} (a /dev/kvm permission probe, probe_kvm() line 220), git, gh, host_claude_bin. Route table: crates/colonizer/src/main.rs (~844–892).
• GET /api/status also returns sandbox {provider, image, cpus, memory, max_parallel, msb_version, claude_bin} — the microVM spec, not measurements.
• The only resource figure on a colony is Session.host_disk_bytes (web/src/types.ts line 57), a one-shot footprint measurement.
• Nothing collects CPU %, memory used/total, load average, uptime or disk free anywhere in crates/.
• Colonies are KVM microVMs named colonizer-<id> (main.rs ~1088); the concurrency ceiling is max_parallel, admitted in crates/colonizer/src/queue.rs.

Why that hurts

An operator cannot tell from the overview whether the box is saturated, how many microVMs are up against the ceiling, or whether a colony is slow because the host is thrashing. Answering that today means SSH and top.

Requested shape

1. Host facts. Extend runtime.rs with a host section: hostname, CPU cores, memory total/used, load average, uptime, disk total/used/free for the data dir. Cache it exactly as Runtime is cached today (10s TTL, ?fresh=1 honoured) so the overview's 4s poll never shells out per request.
2. microVM count. Report live microVMs against the max_parallel ceiling (e.g. 7/12), derived from live sessions — not a new inventory.
3. Per-colony stats. Add to Session with #[serde(default)] so existing sessions.json still loads: the cpus/memory the microVM actually booted with, and guest CPU%/RSS if microsandbox exposes them. If guest stats are unobtainable, say so in a code comment and ship host-level only — never fake numbers.
4. UI. A compact stats strip on each colony row / org card using existing tokens (text-faint, font-mono text-[11px]) and existing icons (IconCpu, IconMemory, IconServer in web/src/components/icons.tsx). Also cheap and already available: colony age, boot_timing total, agent, sandbox image, mesh IP, attention.reason.
5. Keep it scannable — numbers, not sentences. No new dependencies (React 19 + Vite + Tailwind v4, zero runtime deps).

Done when

• GET /api/status returns a host object: hostname, cpu cores, memory total/used, load, uptime, disk total/used/free, microVMs live/ceiling.
• web/src/types.ts documents the new shape; cargo test and npm test (in web/) pass.
• The overview shows host stats with no layout regression at the 300px minimum card width.
• Stats are cached; polling does not spawn a process per request.
• Anything unmeasurable is omitted, never zero-filled.

---

_{Credited to @colonizer-settlers as co-author on this issue.}

[ParallelEntrepreneur]

This is no longer a nice-to-have stats panel — there is a concrete blind spot. The operator runs a second machine (Arch/Omarchy, tailnet hostname archlinux, 100.127.251.53, online) and asked why it has no sessions live. It cannot be answered from the cockpit, and it could not be answered from this host either:

• GET /api/status → mesh.nodes = 5 counts microVMs on this machine, not machines. There is no host inventory anywhere.
• The mothership binds 127.0.0.1:7878 (COLONIZER_BIND), so a second host's API is unreachable over the tailnet by design — every port probed (7878, 41750, 3000, 8080) refused.
• runtime (crates/colonizer/src/runtime.rs) describes exactly one machine: the one the mothership runs on.

So today N machines means N independent cockpits with no aggregated view, and a silent host is indistinguishable from a healthy idle one. Please scope the host panel with that in mind:

1. Even single-host, the panel must make liveness unambiguous — last heartbeat, whether the mothership process is up, whether runtime.kvm.ok is true (a host that cannot boot colonies looks idle, not broken).
2. Design the data shape so a second host can be added later without a rewrite: key everything by a host id, not by "the" host. Whether multi-host aggregation lands now or later is a scope call for the PR — but do not hard-code a single host into the API shape.
3. The telemetry heartbeat already carries {install_id, version, platform, colonies} (crates/colonizer/src/telemetry.rs, services/telemetry) — that is the existing per-install identity to build on rather than inventing a new one.

[ParallelEntrepreneur]

Superseded in part by #231, which is now the dedicated multi-host issue. The host-identity requirement in my earlier comment belongs there: #231 asks for a stable host id (reusing the telemetry install_id) and a GET /api/hosts fleet endpoint. This issue should stay scoped to per-colony and per-host stats on the host you are looking at — but key everything by a host id rather than assuming there is only one, so #231 can aggregate without a rewrite. Whichever lands second reuses the first's identity.