Video upload always fails, and the desktop swallows the reason ("Unknown error")

# Video upload always fails, and the desktop swallows the reason ("Unknown error")

**Type:** bug
**Component:** desktop (media upload), relay (`buzz-media`)
**Relay revision tested:** `f53bbd1` (self-hosted, single pod)
**Date:** 2026-08-07

## Summary

Attaching a video in the desktop app fails with a toast reading

> Upload failed: Unknown error

The relay actually returns a precise, actionable `422` — the desktop discards it.
On top of that, the relay enforces two conditions on video uploads that the
desktop never satisfies and never prepares for, so **every** video taken from a
phone, a camera, a screen recorder or an editor fails.

## Reproduction (verified against a live relay)

Uploading the same 2-second test clip three times, via `buzz upload file`:

| Attempt | Relay response |
|---|---|
| plain `ffmpeg` mp4 | `422 {"error":"moov atom not at front of file (not fast-start)"}` |
| `-movflags +faststart` | `422 {"error":"media contains metadata or a non-canonical metadata channel"}` |
| `-map_metadata -1 -fflags +bitexact -movflags +faststart` | **accepted** — `video/mp4`, `320x240`, `2.0 s` |

So the relay requires, simultaneously:

1. container detected as `video/mp4` (`crates/buzz-relay/src/api/media.rs:50`),
2. **fast-start** (moov atom at the front),
3. **no metadata whatsoever**.

Size is not the issue — `max_video_bytes` is 500 MB
(`crates/buzz-media/src/storage.rs:294`).

## Two defects

**1. The error is discarded.** The relay's 422 body names the exact cause. The
desktop surfaces "Unknown error". A user has no way to learn that fast-start is
missing. Passing the relay's message through would make this self-service.

**2. The desktop does not prepare videos, although its own relay requires it.**
For animated PNG and WebP the desktop *does* strip metadata before upload
(`desktop/src-tauri/src/commands/media_animated.rs` —
`strip_animated_png_metadata`, `strip_animated_webp_metadata`). For video there
is no equivalent: no faststart remux, no metadata strip. A `grep` for
`faststart|moov|map_metadata` across `desktop/src` and `desktop/src-tauri/src`
returns nothing.

Since the conditions are purely structural (remux, no re-encode), they can be
satisfied client-side in well under a second for typical clips — the equivalent
of `ffmpeg -c copy -map_metadata -1 -movflags +faststart`.

## Suggested fix

- Surface the relay's 422 body in the upload toast (at minimum as a details line).
- Remux video client-side before upload, mirroring what the animated-image path
already does, or state the requirement in the picker before the user waits for
an upload that cannot succeed.

## Workaround for other operators

```bash
ffmpeg -i input.mp4 -c copy -map_metadata -1 -fflags +bitexact -movflags +faststart -y out.mp4
```