delivery-kid: port Coconut submit to V2 schema (preview path only)

[magent-cryptograss]

What

Replace submit_to_coconut body with the minimal V2 schema we just verified end-to-end against api.coconut.co/v2/jobs (HTTP 201 on a real POST).

Also: capture Coconut's 4xx response body in the raised exception so the diagnostics panel surfaces the real reason instead of httpx's generic Client error '400 Bad Request' for url ....

Discovery summary

V2 rejected V1's shape with a chain of 400s, each pointing at one rename/restructure:

V2 error	Lesson
The job 'notification' is not a valid object.	webhook → notification: {type, url}
[mp4_preview] Format Container 'mp4_preview' is not valid.	outputs dict key is the format-spec (mp4, mp4:480p, httpstream), not a free-form label
You must define the 'storage' URL if you specify an output with a 'path'.	V2 requires explicit storage — no default hosting
The storage service is not valid. Valid services are s3, gcs, wasabi, dospaces, …, coconut, ipfs_pinata, ipfs_infura.	The most helpful error of the bunch — confirms coconut is a valid service
Output param key 'video' is not valid.	Output values don't accept nested video/audio blocks anymore

Minimal V2 shape that gets 201:

```json
{
"input": {"url": "..."},
"storage": {"service": "coconut"},
"outputs": {"mp4": {"path": "/preview.mp4"}},
"notification": {"type": "http", "url": "..."}
}
```

Scope

• Preview path (include_preview=True): fully V2, single 480p MP4 output, no nested codec blocks. Verified against the real API.

• HLS / finalize path (qualities, trim_start, trim_end): raises NotImplementedError. V2 uses an httpstream output block with HLS+DASH variants whose exact codec/variant shape needs more discovery. Punted to a follow-up PR rather than guessing and re-introducing the silent-400 hell we just escaped.

  Today's failure mode: NotImplementedError → upload_log gets a clear "V2 HLS not yet ported" entry → diagnostics panel surfaces it cleanly. No worse than the silent 400 it produced before, much louder to debug.

What may still need to change after deploy

The V2 job creation shape is nailed down. The webhook callback shape from V2 is not yet observed — _update_draft_preview may need updates to handle a different payload structure (e.g. outputs arrived as an array in the creation response, not a dict; the callback might do the same).

Recommendation: deploy this, retry the upload, and observe the next failure (if any). The improved error capture should make the next iteration ~30 seconds rather than another curl-discovery session.

Why now

Pre-existing breakage of the entire preview transcoding path — any video upload reaches preview_status: failed immediately. Surfaced today by Sky's diagnostics-panel PR #82 finally rendering the underlying httpx 401/400 messages, which let us see exactly what Coconut was rejecting.

Test plan

• Deploy delivery-kid (no --rebuild needed — Python change only)
• Re-upload a small video into ReleaseDraft:1cdc44a0-... (the test draft from this morning)
• Confirm preview_status advances past failed and a Coconut job ID appears in the preview_log
• If the webhook callback handler works → preview_status: ready, side-effect: bot snapshot fires, ReleaseDraft:{id}/diagnostics sub-page should materialize (validates the delivery-kid: snapshot draft diagnostics to wiki sub-page #87 bot path too)
• If the webhook callback handler doesn't recognise V2's payload shape → another iteration, but with clear error in the diagnostics panel