Add a first-class metric emit path to the WASM plugin SDK (signal_type 'metric' / payload_kind 'otel_metric') [serviceradar#3788 REC2]

[mfreeman451]

First-class metric emit path for the WASM plugin SDK

Part of the ServiceRadar unified metric ingestion contract (carverauto/serviceradar#3788, REC2). Today a WASM plugin can only emit metrics by embedding them in a check-result (Result.AddMetric / add_metric_spec → serviceradar.plugin_result.v1), and emit_telemetry supports only ocsf_event and otel_log payload kinds — there is no first-class metric telemetry path.

Evidence: Go sdk/signal_schema.go:15-18 + sdk/telemetry.go (only OCSF/OTEL-log constructors); Rust src/result.rs:354-357 + src/telemetry.rs (only ocsf_event/otel_log).

Ask

• Add a metric signal type + otel_metric payload kind.
• Add a metric telemetry constructor — Go NewMetricTelemetryRecord(...), Rust TelemetryRecord::otel_metric(...) — routed through the existing emit_telemetry host import.
• The metric carries an OTLP-grade point: resource (service identity + attributes), name, kind (gauge/sum/histogram), temporality, is_monotonic, unit (UCUM), and points[] (time_unix_nano, attributes, value or histogram buckets, optional exemplars).
• Keep Result.AddMetric / add_metric_spec as perfdata shims that lower to a single gauge point, so existing plugins keep working unchanged.

This is the producer half of the contract evolving serviceradar.metric.v1 to schema_version 2 (resource/kind/temporality/points[]); the gateway/core consumer side is tracked in carverauto/serviceradar#3788 and update-anomaly-evaluation-cadence (#3791). Contract reference: https://code.carverauto.dev/carverauto/serviceradar/issues/3788