test: pin the set of new() constructors that fabricate readings

HANDOFF item 10 ended with an instruction — "assume any other T::new() in
this crate may be a zero-constructor until checked" — and nobody had
checked. A note is not a check. Two more of the same shape had arrived in
the meantime without being recorded: PowerStats::new() reports 0 W and
0 average, ProcessStats::new() reports 0 KB of GPU memory.

Neither is a live defect. Every call site is inside a platform reader that
fills the struct immediately, which is the legitimate builder-base use — the
same use MemoryStats and CpuStats have. What was missing is anything that
notices a fifth arrival, or a call site that ships one to a caller as a
reading. That is how the first two got out: 0% and 100% idle rendered on a
dashboard as measurements.

So the check now runs. Every argument-free new() in the crate is classified
and compared against a known list of four. A new one fails CI until it is
deliberately acknowledged, and removing one that was fixed fails too, so the
list cannot rot in either direction.

Verified the detector actually detects, three ways: dropping a known entry
reports it as unexpected; adding a bogus entry reports it as no longer
detected; and appending a genuine zero-constructor to src/sandbox.rs was
caught by path. All three controls were reverted and the clean run
re-confirmed. Re-verified after the clippy-driven rewrite of two loops,
since a rewritten detector proves nothing on its own.

The real fix remains a rename to empty() or zeroed(), which is breaking and
stays queued for the next major version.

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