fix(uploads): refuse an unsupported video before uploading it

[JDProfresh]

_promptAttachKind returned video for any video/* MIME, so an Android .3gp (video/3gpp) or an .mkv (video/x-matroska) streamed all the way to disk, up to the 1GB cap, before the ?kind=video route refused it with a 400.

I mirror the server's own video admission in the client: a video MIME now counts only when it names one of the five containers the route accepts (video/mp4, video/quicktime, video/x-m4v, video/webm, video/ogg), the same set as VIDEO_ATTACHMENT_EXTENSIONS (mp4/webm/mov/m4v/ogv). Anything else falls through to the existing extension check, which already rejects 3gp and mkv, so an unsupported clip is filtered client-side and gets the existing unsupported-file toast right away instead of after a long upload. An admitted container still classifies as video by MIME (iOS hands .mov over as video/quicktime) or, when a file manager supplies no MIME at all, by its name's extension, exactly as before.

This is the follow-up you suggested on #606.

Tests: extended test/toolbar-attach.test.ts to pin that the five admitted MIME containers return video, and that a video/3gpp and a video/x-matroska return null while an admitted extension still rescues an odd MIME. I confirmed the new case goes red when the guard is reverted.

Verified: full npm test gate green (11259 passed, 12 skipped), plus typecheck, lint, format:check, check:frontend-syntax and check:browser-excludes.

One gap this leaves, which is older than this PR and not specific to video: when a selection mixes a file the server takes with one it does not (a photo and an mkv, or on master today a photo and a pdf), the refused one is dropped without a toast, and the Compose and paste-dialog pickers never toast for a refused file at all. The toast only fires when every file is refused. I kept this PR to the one line; happy to send partial-rejection toasts as their own change if you want them.

Note: #621 (documents, sent alongside) adds a document branch to the end of this same function, so whichever of the two lands second needs a trivial rebase on the adjacent lines.

[Ark0N]

Merged and shipped in 1.42.0. Thanks @JDProfresh!

Matching the server's exact five video containers on the client, so a 1 GB upload headed for a 400 never starts, is the right fix. I checked it in a real file chooser: .mkv and .3gp get "Unsupported file type" right away with no request sent, and mp4 and a MIME-less .MOV still upload. It also stops a .ts file that a phone labels video/mp2t from counting as a video. It merged with #621 after a one-line doc-comment conflict.

And yes please to the follow-up you offered: a toast for the refused files in a mixed selection, and for the Compose and paste-dialog pickers.