feat(ontology): kernel parameters, split from this crate's opinions about them

`name`, `value` and `category` are what the platform reported and are published.
`is_recommended`, `recommended`, `security_score`, `network_score` and the
free-text recommendations are this crate's judgement about what the values ought
to be, and are deliberately absent: `simon tune`'s standing rule is that a
proposed value comes from what the system declared, never from this crate. A
score sitting beside a measured value borrows its authority.

Two defects came out of doing it, both in the tooling meant to prevent exactly
this class of thing.

**The probe table contained a hardcoded count.** `kernel_params` was `|_| 1` --
a literal that measured nothing -- so the table reported "answers here, 1 item"
for a reader that answers nothing on this machine. That table exists precisely
because "guessing which readers answer was slow and got one of them wrong", and
the guess had been sitting inside it. It propagated into HANDOFF.md's table and
into the plan for this change. `memory_bandwidth` and `crypto_accel` had the
same shape; all three now count something real, and the memory one reports 0
unless the generation was identified, since everything it produces rests on that.

**The Windows reader fabricated a row.** `Get-NetTCPSetting … -ExpandProperty
AutoTuningLevelLocal` fails outright here -- a null-conversion error, nothing on
stdout -- and the code pushed a `KernelParam` anyway with `value: ""`. A named
setting that appears to exist and be blank is worse than an absent one. It now
skips an empty value, and the snapshot correctly carries
`system.kernel_param.<none>` with a reason.

Verified: fmt, clippy --all-targets -D warnings, 826 lib tests, conformance 21,
honesty 7, agentic_contract 16, and the snapshot rows read by eye.

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