fix: two more constants wearing a measurement's provenance

Both found by the same scan that caught the CPU frequency: readers that
return an identical value for every instance, which is what a broken
per-device reader looks like from outside.

`disk.controller.{n}.ports` read 1 for all three NVMe controllers. The
Windows paths hardcode it — they learn nothing about a port or namespace
count — while the sysfs path uses the real namespace count. The entity is
declared `Measured`, described as "port count the controller reports", and
its own text already says "Nullable rather than zero: a controller that
reports no count still has ports". The resolver had the honest branch
waiting, keyed on zero, and the reader never used it.

`system.printer.{n}.color` read `false` for every printer, and three of the
four on this machine print in colour. The cause is that `Win32_Printer` has
no `Color` property at all: the query asked for one, WMI returned null for
every row, `as_bool()` gave `None`, and `unwrap_or(false)` published
monochrome as a measurement. Colour lives in `Capabilities`, a `uint16[]`
where 2 means Color — the same array whose `CapabilityDescriptions` spell it
out. `PrinterInfo::color` is now `Option<bool>` (one real consumer), the
entity is nullable, and a spooler that lists no capabilities produces an
absence rather than a claim of monochrome.

That is the third time this session the same shape has appeared: a property
that does not exist under the name being read, a fallback beneath it, and a
plausible wrong answer published as `Measured` — after `MediaType`/`BusType`
arriving as strings, and `AdapterRAM` overflowing 32 bits. The fallback is
what makes it silent in all three.

Verified against WMI: the three virtual printers now read true and the mono
Brother laser reads false, matching `CapabilityDescriptions` exactly.

The whitespace test added in 2f7be76 earned itself back here — it caught the
collapsed indentation in my own new declaration text before it shipped. The
matching absence reason was rewritten with `concat!` too, since it only
fires for a printer that reports no capabilities and so is untested on this
host.

Note for whoever hits it next: `target/` had grown to 129GB and C: was at
100% with zero bytes free, which surfaced as a bogus "failed to write
.rmeta" compile error. `rm -rf target/debug/incremental` freed 49GB and is
pure cache; `target/debug/examples` is another 39GB.

Verified: fmt, clippy, both cross-target checks, and ontology_conformance
(22), honesty (16), plausibility (7), agentic_contract (11).

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