feat(ontology): eleven clusters, and the defects reading their output found

Adds memory.bandwidth, cpu.microarch, cpu.crypto, board.input, board.audio,
board.camera, system.printer, network.bluetooth, disk.controller, power.profile
and gpu.codec, each with its own `<none>` diagnostic per the sub-cluster rule.
`examples/probe_readers.rs` turns "which cluster next" into a table rather than
a guess.

Five honesty defects, every one found by running `simon snapshot --format text`
and reading the rows rather than by a test:

- memory.dimm.* declared SMBIOS data as Measured; a part number is what the
  firmware said, not what was measured off the module. Now Specification.
- cpu.microarch.name emitted `{:?}` of a whole struct into a reading declared
  as an identifier. Split into name, codename, vendor, isa, process, year,
  hybrid.
- CPUID family/model/stepping published 0 on Windows, where the triple is never
  decoded. Family 0 identifies no x86 part that has shipped, so it means "not
  read"; all three now go together or not at all.
- The Windows camera reader accepted PnP class `Image`, so a scanner appeared
  as two cameras -- a wrong answer to "can this machine see".
- disk.controller.pci_address published device instance paths like
  `ROOT\SPACEPORT\0000`, which cannot be joined against pci.* and would send a
  consumer looking for a link width to a bus the device is not on.

gpu.codec.* picks provenance per row -- the only cluster that does. A queried
capability resolves Measured and an inferred one Specification, because the two
look identical until you ask and only one survives a driver update.

Scores are deliberately withheld. cpu_microarch and crypto_accel each compute
one, but both are table lookups keyed on a name rather than measurements of the
processor present, and no provenance fits: Measured lies about the method,
Derived about the inputs. Serial numbers and Bluetooth MACs are readable and
also withheld -- they identify a unit rather than describe it.

Five entities were declared non-nullable that the readers can legitimately not
answer, which `non_nullable_entities_are_never_null` caught: the CPUID triple
above, absent on Windows by the very fix that made it honest, and
system.printer.{n}.{connection,status}, where the spooler itself reports
"Other" and "Unknown" states. Declared nullable, each saying why.

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