Add detailed render telemetry and concise video status

[Artsen]

Summary

• add a bounded, thread-safe runtime telemetry model for queued and active video jobs
• report FFmpeg frame/time/speed/size progress, rolling and average FPS, ETA, queue position, stale state, and explicit finalization phases
• persist bounded milestones, coarse frame checkpoints, and terminal timing summaries while retaining manifest schema v2 compatibility
• expose full telemetry on individual job responses and compact status fields in job lists
• add a concise, responsive, keyboard-accessible video status UI with safe polling, cancellation feedback, previous-output retention, and screen-reader announcements
• bump the application to 0.2.1 and the video-job API contract to v2; manifest/storage remain v2 and recipes remain v1

Telemetry contract

The v2 video-job contract uses these phases: waiting, preparing_source, applying_effects, finalizing_output, verifying_output, saving_output, completed, failed, and canceled.

Runtime snapshots use a monotonic clock for elapsed calculations and UTC timestamps for serialization. Frame updates are capped at approximately 4 Hz, history is bounded, ETA is derived from progress and elapsed time, and active telemetry becomes stale after approximately five seconds without an update. Queue snapshots include position, depth, concurrency, and active-worker counts.

FFmpeg finalization now uses -progress pipe:1 -nostats. Dedicated bounded stdout/stderr readers parse progress without allowing either pipe or retained diagnostics to grow without limit, while cancellation still terminates and escalates to kill when required.

Persistence behavior

The manifest schema remains v2. Video job records now preserve bounded phase milestones, terminal timing summaries, and coarse frame counters. Existing 0.2.0 records are accepted and their phase is inferred from their prior state. Restart reconciliation reconstructs useful terminal telemetry and retains explicit cancellation/failure outcomes without attempting to persist high-frequency runtime samples.

UI behavior

The primary status stays intentionally concise: truthful phase text, progress, ETA or queue context, and cancellation state. A semantic details disclosure contains frames, FPS, speed, size, elapsed time, ordered effects, and phase history. Polling maintains one timer and one request, guards stale job revisions, backs off by job state, retries transient network failures, and stops at terminal states. Announcements are throttled to phase changes, meaningful progress thresholds, periodic elapsed milestones, and terminal outcomes. A prior successful output remains available while a new render runs.

Validation

• python check.py through .venv: 213 tests passed
• statement coverage: 3,006 / 3,101 (96.94%)
• branch coverage: 561 / 622 (90.19%)
• combined coverage: 95.81%
• Ruff formatting and lint: passed
• Mypy: passed for 34 source files
• repository consistency: passed
• Playwright Chromium: 7 workflows passed, including responsive video telemetry and cancellation
• axe: no serious findings in the covered keyboard workflow
• real FFmpeg/FFprobe integration: passed, including H.264/yuv420p/AAC output, duration/speed progress, phase order, and persisted timing summary
• controlled queue, frame, cancellation, restart, malformed-progress, bounded-buffer, and throttling scenarios are covered by deterministic automated tests
• telemetry microbenchmark: approximately 0.66 microseconds overhead per callback across 10,000 callbacks on the development machine
• GitHub Actions: quality and browser passed

Known limitations

• ETA and FPS stabilize only after enough frame samples and remain estimates.
• FFmpeg fields vary by build; malformed or unavailable fields are ignored instead of failing the render.
• Runtime high-frequency samples intentionally disappear on process restart; durable milestones, coarse counters, and terminal summaries remain.
• Queue positions are snapshots and may move as jobs finish or are canceled.
• The UI polls rather than using server push, with active jobs sampled at roughly 750 ms and queued jobs at roughly 1.2 s.