Task: Show the services in system health

The system administrator's home answers "is the installation healthy" in one place. Its System health panel counts tenants alone today: in service, on evaluation, setting up, and those that need attention (the home.system keys in ores.web). The panel splits into sections, one per kind of thing that can be unhealthy: Tenants, as now, and Services, from the services roster. The services section states how many expected instances are running, and names the ones that are lost or missing, with a link to the services screen. Further sections, such as the compute grid or the message bus, can join the same shape later.

• System health on the system administrator's home has a Tenants section and a Services section, each with its own summary line and its own attention list.
• The services section reads telemetry.v1.services.roster through a BFF route, states running instances against expected ones (for example 20 of 21 running), and lists each lost or missing service by its display name, with a link to the services screen.
• When the roster cannot be read, the section says so, and the tenants section still renders.
• Every new string is in each locale the web client carries, and the home page tests cover both sections, including an unreadable roster.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Raised by the operator on 2026-10-06. It reads the roster that Serve the services roster serves, and its states grow when Record service starts and stops adds a graceful stop. The full roster stays on the services screen (Build the operations screens in ores.web); the home shows the summary and the exceptions.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.