SIGN IN SIGN UP

fix(readers): nine readers said "none" where they meant "cannot look"

Twelve non-Linux branches across nine modules returned `Ok(empty)`, so "this
platform cannot answer" and "this machine has none" were indistinguishable --
the defect RAPL shipped once, still present everywhere else. Each now returns
`UnsupportedPlatform` naming the sysfs path it would have read.

Two were worse than stubs, and both were confident wrong answers rather than
silences:

- `security_mitigations::detect_vulnerabilities` returned an empty list on
  Windows with a comment noting the real check needs Administrator, so
  `unmitigated()` reported zero. The crate answered "no unmitigated CPU
  vulnerabilities" when it meant "nothing was checked". Of every absence here
  that is the least acceptable to guess at: a reassuring security reading is
  acted on.
- `iommu::scan` on Windows derived an IOMMU type from the PROCESSOR_IDENTIFIER
  environment variable and reported `enabled: false`, its own comment admitting
  it cannot detect reliably without admin.

`security_mitigations` keeps its real Windows implementations elsewhere; only
the vulnerability probe was a stub.

Reading the probe output caught three defects in this change itself -- a
subject/verb disagreement, two distinct paths inside one pair of backticks, and
a helper orphaned by the edit that would have failed clippy. The habit works on
one's own output too.

Verified: `probe_readers` shows all nine declining with a reason and no `none`
rows; clippy `--all-targets -D warnings` clean; 826 lib tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A
Adam Erickson committed
ebab95654d9d5c3eba1cfe935caf8d8605e2e214
Parent: 2687dbb