Generate events from a declarative registry (events.toml)

[chet]

Dmitry's suggestion from the framework PR (#3192): keep the Event model, but stop hand-writing the event structs -- declare them in an events.toml registry and generate the derive-annotated structs from it. The registry then becomes the source of truth for docs/observability/core_metrics.md, turning the catalogue from observed-partial (whatever test_integration happens to exercise) into declared-total, with the integration test acting as a verifier of exposure instead of the generator of the docs. Messages-in-data also opens future i18n.

What this involves

• An events.toml schema (likely per-crate files, keeping event declarations near the code that emits them) naming each event's metric name, component, knobs, message, describe, and its label/context fields. The type-reference plumbing for field types (Backend, MachineId, ...) is the main design problem.
• A generator (xtask or build.rs; see nv-redfish's csdl-compiler for the house codegen pattern: https://github.com/NVIDIA/nv-redfish/tree/main/csdl-compiler/src/generator) that emits the same #[derive(Event)]-annotated structs -- the existing derive keeps doing the validation and codegen, so the runtime model (the Event trait, the log/metric knobs, the LabelValue cardinality guards, emit(), the capture helpers) is untouched.
• core_metrics.md generated from the registry; test_integration flips from doc-generator to exposure-verifier. Pairs with the CI doc-gate in Unify metrics exposition and log format; codify the instrumentation standard #3180.
• A mechanical harvest of the hand-written #[event(...)] attributes into the registry -- the attribute is already declarative data, so nothing written before this lands is stranded.
• Sequencing: after a sweep or two (Light up the dark subsystems: scout, nras, nvue-client, kms-provider #3173-Close the data-plane egress gaps: health sinks, MQTT, agent report loops #3178) so the schema is designed against real usage patterns rather than guessed.

Suggested by @poroh in #3192.

Part of #3169.