fix!: rename the zero-constructors, and fix the three defects that found

The rename was queued as cosmetic tidying. It was not. `CpuStats::new()` and
its three siblings returned fabricated numbers behind a name that reads like
a reader, and going to change it turned up three places that had been
believing them.

`SiliconMonitor::snapshot_cpu` and `snapshot_memory` are public API,
documented as "snapshot current statistics", and returned the
zero-constructor. Every library consumer received 100% idle, no cores, and no
memory. They now read the platform — 24 cores at 76.7% idle on this machine,
where they previously reported nothing at all.

`SystemHealth::check` computed CPU usage as `100 - idle` from the same
constructor, so it always saw 0% and no threshold could ever be crossed. A
health check that cannot fire is worse than none, because its silence is
read as good news. It now reports 23.4% CPU, 51.4% memory, and correctly
flags elevated swap.

The Prometheus exporter published 0% CPU on every scrape — the same
arithmetic, in the integration whose whole purpose is to be believed by a
time-series database.

That is the third, fourth and fifth defect from this one pattern; two in the
GUI and one in the HTTP server came earlier. The name was doing the damage.

BREAKING: the four constructors are now `empty()` returning `Self` rather
than `Result<Self>`. Building a zeroed struct cannot fail, and the `Result`
invited a `?` that made call sites read as though they had gathered
something.

`tests/zero_constructors.rs` keeps running and its list is now empty: no
`new()` in this crate fabricates a reading, and adding one fails the build.
Verified by injecting one — the list being empty is a state the test enforces,
not a state it stopped checking.

Version 6.0.0; 5.2.0 was never published, so this is the first release the
break reaches.

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