feat(signals): steering for error tracking, session replay and health checks sources #90188

Problem

Per-source steering (SignalSourceConfig.config.steering and default_not_actionable, products/signals/backend/emission/steering.py, applied in emission/pipeline.py) is the customer's way to say what matters and what to skip for a source. It only exists for sources that go through the shared emission pipeline: Support, GitHub issues, Linear, Zendesk and pganalyze (steerable: true in products/signals/frontend/inbox/components/config/agentRosterMeta.ts).

Error tracking (issue_created, issue_reopened, issue_spiking), session replay clusters and health checks emit signals directly through emit_signal and skip the actionability gate entirely, so there is nothing for the customer to steer and no place for a rule like "ignore issues whose events all come from local development hosts".

When a customer asks how to stop a class of error-tracking reports, the only answers today are turning the source type off or building a custom scout. Neither is a good answer to "I just want you to ignore localhost".

Fixes

1. Route direct emitters through an actionability gate that honours steering. Either move error tracking, replay and health checks onto the emission pipeline with a per-source actionability_prompt, or add a lightweight gate inside emit_signal (products/signals/backend/facade/api.py) that reads the source's SignalSourceConfig, applies apply_steering, and drops the signal when the gate says NOT_ACTIONABLE. The second is smaller and keeps the emitters unchanged.
2. Give the gate something to read. The steering text needs record metadata to act on; include_record_metadata=steering.active in the pipeline already passes extra. Error tracking should put host and dev-host facts into extra (tracked in fix(error-tracking): signals omit the event origin, so dev-host noise becomes duplicate reports and PRs #90178) so "skip localhost" is expressible.
3. Mark the sources steerable in agentRosterMeta.ts so the existing SourceSteeringModal opens for them. No new UI.
4. Telemetry parity. Emit the same signal_data_source_filtered stage event with steering_applied so filtered error-tracking signals are visible in the pipeline funnel.
5. Tests: steering text that excludes a described pattern drops the signal; empty steering leaves behaviour unchanged; default_not_actionable on error tracking keeps only clearly actionable issues.

Why

Steering is already built, documented and in the UI; it is just not wired to the sources that generate most reports. Extending it closes the gap where the honest support answer is "write a custom scout".

From this Slack thread; the investigation is written up in the self-driving-debugging skill in the skills store.