# Telemetry Forwarding from Mission Executor

**Task**: AZ-649_mission_executor_telemetry_forwarding
**Name**: Telemetry forwarding to scan, movement, telemetry, BIT input
**Description**: Forward decoded MAVLink telemetry (position, attitude, mode, sys-status) from `mavlink_layer` to `scan_controller` (proximity + middle-waypoint computation), `movement_detector` (ego-motion compensation), and `telemetry_stream` (operator overlay). Provide a typed `UavTelemetry` snapshot for BIT consumption.
**Complexity**: 2 points
**Dependencies**: AZ-640_initial_structure, AZ-648_mission_executor_state_machine
**Component**: mission_executor
**Tracker**: AZ-649
**Epic**: AZ-636

## Problem

`mission_executor` is the only component subscribed to the raw decoded MAVLink stream — it owns the airframe relationship. Downstream components (`scan_controller`, `movement_detector`, `telemetry_stream`) and the BIT path need the same telemetry, but in a typed, projection-friendly form (`UavTelemetry { position, attitude, mode, sys_status, monotonic_ts }`). Forwarding must not duplicate decode work and must not drop messages silently.

## Outcome

- `UavTelemetry` is published on three lossy broadcast channels (one per downstream consumer) with monotonic timestamps; consumers that fall behind get drops counted, not blocking.
- `UavTelemetrySnapshot` (latest-state view) is exposed for BIT and health-check consumers.
- Health surface: `last_telemetry_ts`, per-consumer drop counters.

## Scope

### Included
- Subscribe to the typed `MavlinkMessage` enum from `mavlink_layer`.
- Project to `UavTelemetry` (`data_model.md §UavTelemetry`).
- Publish on three Tokio broadcast channels.
- Maintain an atomic latest-snapshot for synchronous reads.

### Excluded
- Decoding MAVLink (task 03).
- Geofence/battery checks (task 13).
- BIT logic (task 11).

## Acceptance Criteria

**AC-1: Telemetry reaches all three consumers**
Given a healthy SITL link
When `GLOBAL_POSITION_INT` and `ATTITUDE` arrive at 10 Hz
Then `UavTelemetry` is observed at ≥10 Hz on all three downstream channels, with monotonic timestamps.

**AC-2: Slow consumer drops, fast consumers unaffected**
Given a slow consumer that yields every 500 ms while telemetry arrives at 10 Hz
When the channels back-pressure
Then the slow consumer's drop counter increments while the other two channels deliver every frame.

**AC-3: Latest-snapshot is monotonic**
Given a sequence of telemetry messages with monotonically advancing timestamps
When `latest_snapshot()` is read concurrently
Then every read returns a snapshot whose `monotonic_ts` is `>=` the previously observed value.

## Non-Functional Requirements

**Performance**
- Telemetry republish adds ≤2 ms to the MAVLink decode-to-consumer path.

**Reliability**
- Slow consumer never blocks fast consumers (lossy broadcast).
- Drops are counted, never silent.

## Runtime Completeness

- **Named capability**: typed telemetry fan-out to three concurrent consumers.
- **Production code that must exist**: real Tokio broadcast or equivalent; real atomic snapshot.
- **Unacceptable substitutes**: blocking single-consumer queue is not acceptable (it would gate the slowest downstream).
