Add a pluggable media uploader so large video downloads don't OOM serverless runtimes

Spinning out a follow-up flagged in PR #409 review (https://github.com/TanStack/ai/pull/409#discussion_r2218600385 / r2218663501).

OpenAICompatibleVideoAdapter.getVideoUrl falls through to videos.downloadContent/content/getContent/download and a raw fetch for backends that don't return a CDN URL on retrieve(). In every fallback path we read the entire video into an ArrayBuffer, base64-encode it, and emit a data: URL. PR #409 added a >10 MiB warning (warnIfLargeMediaBuffer) but the underlying behaviour is still unsafe on Workers / Lambda / small isolates.

This will almost certainly blow up workers. It's pretty common for videos to be bigger than 100mb. — @tombeckenham

Downloading the video and base64'ing it will cause most backends to run out of memory. I'm wondering if we support these older methods at all. At the very least we should add a warning with logger and look at whether buffers are over e.g. 10mb. It's quite hard to figure out where memory issues come from as they don't necessarily occur at the point this blob would be created. I'm wondering if we might want to add a media uploader function to the the constructor in a future PR — @tombeckenham

Scope

• Design a mediaUploader (or MediaUploadStrategy) constructor option on OpenAICompatibleVideoAdapter (and likely image/audio adapters too) that takes a stream-or-blob and returns a public URL.
• Default behaviour: if no uploader is configured AND the SDK doesn't expose a retrieve()-time CDN URL, return a VideoUrlResult that surfaces "upstream URL not available; provide a mediaUploader to download/host the bytes" rather than silently base64ing.
• Promote the current warnIfLargeMediaBuffer to flow through the InternalLogger instead of console.warn once a logger is plumbed through these methods.
• Apply the same strategy to TTS / image adapters where a base64 data URL is emitted today (see also the response-input-file base64 follow-up @tombeckenham mentioned).

Related

• PR #409 review thread on video.ts:148 and video.ts:165.
• The existing responses-text.ts base64 data-URI thread (https://github.com/TanStack/ai/pull/409#discussion_r2218493238) — Tom mentioned an in-flight PR removing that for input attachments; this issue covers the symmetrical concern on the output side.

cc @tombeckenham