Make stuck machines and provisioning outcomes alertable

[chet]

The two mechanisms that strand a machine -- state-handler enqueue failure and accumulating retry_count -- are logged or persisted but never metered, and firmware/validation outcomes are uncountable. This makes "stuck" alertable.

What this involves

• State-handler wake-up/enqueue-failure counter (machine_scout.rs, host_reprovisioning.rs, dpu.rs) -- if the enqueue fails, the machine silently stops being driven; that's the stuck-machine mechanism and it's warn!-only today.
• Reprovision retry-depth gauge/histogram -- retry_count is persisted today and exported nowhere, so "machines churning on retries" has no signal.
• Firmware update started/completed/failed counters by cause -- including the "wrong version after attempted update" case that's warn!-only today.
• Machine-validation and measured-boot outcome counters (by alert cause, so stale-timeout storms and genuine test failures are distinguishable) + collector iteration duration.
• A periodic-loop heartbeat (iterations, last-success-age, error counter) for every background manager -- a wedged loop only shows as stale gauges today. And make the health discovery loop retry instead of terminating on first failure.
• Add the state-controller framework's missing _object_tasks_errored_total -- the per-iteration log line has errored_tasks, the metric family doesn't.

Depends on the carbide-instrument framework. Fans out as a few PRs at pickup.

Part of #3169.

[chet]

PR #3272 opens this (stuck-machine core first; the firmware-outcome, validation/measured-boot, and loop-heartbeat PRs follow per the fan-out note).

[chet]

Follow-up candidate surfaced by review on PR #3272: InstanceState::HostReprovision carries no retry_count, so instance-assigned hosts retry firmware upgrades without a budget -- they can never reach the exhausted state (and are therefore invisible to carbide_exhausted_reprovision_retry_count by construction). Giving assigned hosts a retry budget is a machine-state schema change with recovery-behavior implications; if we want it, it should be its own change. Their churn is meanwhile visible as a sustained per-machine carbide_host_reprovision_retries_total rate.