Publish a live view failure event when the capture pipeline cannot start

[robertjamesprior]

A live view whose capture pipeline cannot start currently leaves no trace outside the VM's own log: the viewer connects, receives no frames, and the client has nothing to report. The telemetry plugin already forwards session connect/disconnect, so this adds the failure alongside them and carries a code the control plane can classify on.

What changed

• live_view_failed is published into the connection category with session_id, a code, and the pipeline error message.
• The code is gpu_encoder_unavailable when the error names the encoder stack (no element "nvh264enc", a CUDA context failure, nvenc, a plugin load failure) and live_view_pipeline_failed otherwise.
• The websocket handler reports it from the existing error path when a signal/request fails, which is where a pipeline that cannot start surfaces. Reporting goes through a package-level hook rather than a plugin reference, so the handler does not depend on the plugin manager, and it is a no-op when the plugin is disabled.
• eventPayload gained a category so an event can choose one; existing events default to system and are unchanged.

Why it matters

A percentage of live views fail because the GPU is already holding a video encoder session for the replay recorder. Nothing measures that today: support reads the VM log by hand, and only after a customer reports it. This makes the failure countable per session and per org, and gives alerting something to key on.

Testing

• go test ./internal/plugins/telemetry/ passes, including three new cases: the event shape it publishes, the no-op path with no reporter, and the error classification table.
• go build ./internal/websocket/... and go vet on both touched packages pass. The local VM needed the GStreamer and X11 dev headers installed to build; CI has them.
• No handler tests exist for this package, so the call site is covered by build and vet only.

Not in this PR

The control plane, dashboard and docs rows for the new event type. Unknown types are accepted by the ingest endpoint when a category is supplied, so this ships independently and the rest can follow.