MediaDownloadError: decide its retry flag and whether an HTTP-error signed URL should raise it (from #898) #941

Two decisions split out of #898, raised by the PR #912 council. Each one changes a public contract, so neither was folded into the #898 fix.

1. MediaDownloadError is retryable (inherited from NetworkError)

get_signed_media raises it for two callers whose needs are opposite:

• The generation download (gflow video / image). The clip exists and is billed. If a scheduler follows docs/MCP.md / USAGE.md and re-runs anything marked retryable: true, it bills again. The right action is gflow data download / gflow_download_media.
• The gflow_download_media recovery tool. Here a retry is correct and spends nothing (MCP.md documents "pause and call again").

A single class-level flag can't be right for both. Options:

• Set retryable per raise site, by caller.
• Raise a distinct subclass from the generation path.
• Keep the flag as it is and change the remediation text.

2. An HTTP error answer on the signed URL still leaves the asset pending

After Flow reports the clip done, an error status from the signed URL (an expired link, for example) raises WireFormatError (exit 7):

• migrated_composer.py: status ≥300
• ui_automation_video.py: status ≥400

Both messages already say the clip exists (expired_link_hint). Raising MediaDownloadError(media_id=…) there would mark the asset generated, but it would change exit 7 to 6.

Evidence needed before deciding

Which callers branch on exit 6 or 7 or on retryable: CLI scripts, the MCP worker, and the docs.