Feature: Stream quality scoring and remediation recommendations

## Summary
Add a stream quality service that scores camera health and recommends remediation when visual or transport quality degrades before perception results become unreliable.

## Problem / Opportunity
AegisVision exposes stream health and observability signals, but operators need domain-specific quality insight: blur, darkness, glare, occlusion, dropped frames, frozen frames, timestamp skew, and unstable FPS. These conditions can create bad detections and false drift signals even when services are technically healthy.

## Proposed Feature
Create a stream quality capability that continuously samples lightweight frame descriptors and transport metrics, emits per-stream quality scores, and provides remediation recommendations. The score should be available to SLO/drift views, events, console dashboards, and agent answers with citations.

## Scope
- Define quality dimensions and scoring schema for visual and transport health.
- Add periodic lightweight analysis in the data plane without sending frame bytes through the control plane.
- Persist quality summaries and significant quality incidents.
- Expose APIs for current score, history, and recommended actions.
- Add console cards/trends and event annotations when quality explains detection degradation.
- Document thresholds, tuning, and operational response.

## Acceptance Criteria
- [ ] Each active stream has a current quality score with component breakdowns.
- [ ] The system detects frozen frames, severe blur, low-light frames, dropped-frame bursts, and timestamp skew.
- [ ] Quality incidents generate tenant-scoped events with traceable stream and time-window references.
- [ ] Drift/SLO views can display quality as contextual evidence for degraded perception.
- [ ] The agent can cite stream quality records when answering reliability questions.
- [ ] Docs include recommended operator actions for each quality dimension.

## Non-Goals
- Replacing existing service readiness or bus health metrics.
- Performing heavyweight inference on every frame just for quality scoring.
- Automatically changing camera settings in the first release.

## Dependencies / Risks
- Must keep per-frame overhead low and preserve two-plane separation.
- Quality scores can be misused as absolute truth; documentation should frame them as indicators.
- Some visual quality checks may need tunable thresholds per camera type.

## Open Questions
- Should quality scoring be an operator in the existing DAG or a sidecar sampler?
- Which quality incidents should contribute to SLO burn-rate calculations by default?