feat(macos): wire the CPU and memory readers into the ontology resolver

`ontology::resolve::read_cpu_stats` and `read_memory_stats` had no macOS
arm. They returned None unconditionally, and the resolver then reported
"the platform CPU reader returned an error" — which was false. No reader
had been called. Reporting a fabricated cause for an absence is the exact
mistake this crate exists to avoid, and it was sitting in a note string.

Eight entities were affected on macOS: cpu.total.utilization, memory.total,
memory.used and memory.utilization as "reader returned an error", and
cpu.model, cpu.cores.logical, cpu.cores.physical and cpu.total.idle as "no
resolver bound on this build" — all four of those non-nullable, so the
schema was promising values it never delivered.

Everything needed was already in platform/macos.rs and unused:
per_core_ticks (the only source of nice time), aggregate_ticks, vm_stat,
sysctl_u64, swap_usage. This adds the two adapters that assemble them into
CpuStats and MemoryStats, and wires both resolvers.

Where macOS genuinely has nothing, it says so rather than inventing:
governor is left empty, which the resolver converts to unavailable with a
reason, and per-core frequency is None because no unelevated source exists.
A nominal figure there would repeat precisely the Windows CurrentMhz problem
documented in tuning::verify.

Only visible now because cargo test stops at the first failing binary and
documentation_links sorts before ontology_conformance: fixing the prose test
is what let this one run.

Compile-checked against aarch64-apple-darwin. It has never executed — there
is no Mac here — so macos-latest in CI is the check, exactly as open work 2
says.

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