fix(ontology): bandwidth published defaults; services becomes a summary

Two changes to the same two files, kept together because splitting them
hunk-by-hunk was not worth a rewritten history.

**memory.bandwidth published defaults when nothing was read.** CI showed
`generation` resolving unavailable while `achievable` and `stream_triad`
resolved fine, and `86fe1fd` recorded that as a declaration overstating a
dependency. It was the opposite: the derivation really does need the generation
and proceeded without it. An unidentified generation does not stop the
estimator -- it substitutes 3200 MT/s, a 64-bit bus and a 0.75 efficiency
factor, none of which is a fact about the machine in front of it. A VM's SMBIOS
routinely names no generation, which is exactly what both CI runners see, so on
those the transfer rate shipped as `Specification` and three bandwidth figures
as `Derived` with nothing separating them from figures that had been read. The
chain is now withheld with a reason and the four entities are nullable.
`channels` still resolves: it is detected independently.

The general shape, which the ontology cannot currently express: a derived
reading must not resolve when a declared input did not. Worth a conformance test
if a second instance turns up.

**`services` is now counts plus the names of the failures.** 311 services here,
so one entity per service would more than double every snapshot to carry a list
nothing reads in full. `system.service.count.{total,running,failed}` and
`system.service.failed.{n}` answer what a consumer actually asks -- how much is
wrong, and what. Verified on this machine: 311 total, 132 running, 0 failed.

Zero failures is a measurement, not an absence: `system.service.<none>` is
reserved for the service manager being unreachable, because a machine with
nothing broken and a machine that could not be enumerated must not look alike.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>