Fix server API key fallback when client echoes provider base URL

[LooThao]

Summary

Fix server-configured providers losing their API key when the client sends back the same server-provided base URL.

This expands the original TTS fix to the shared provider resolution path and the media/document routes that use server-side provider credentials.

Problem

Several API routes treated any request containing a Base URL as a fully client-configured provider. The settings UI can echo a server-configured Base URL back to these routes while leaving the client API key empty. In that case server-configured providers fail with missing API key errors even though the key exists on the server.

Examples include MiniMax TTS/LLM, image generation, video generation, transcription, and PDF provider routes.

Fix

Add a shared canUseServerApiKeyForBaseUrl guard and use it across provider routes:

• use the server API key when no client Base URL is provided
• use the server API key when the client Base URL matches the server-configured Base URL
• require a client API key when the client sends a different custom Base URL, so server secrets are not forwarded to untrusted endpoints

Covered routes:

• /api/generate/tts
• /api/generate/image
• /api/generate/video
• /api/verify-image-provider
• /api/verify-video-provider
• /api/transcription
• /api/parse-pdf
• /api/verify-pdf-provider
• shared LLM model resolution via resolveModel

Test

pnpm exec eslint app/api/generate/image/route.ts app/api/generate/video/route.ts app/api/verify-image-provider/route.ts app/api/verify-video-provider/route.ts app/api/transcription/route.ts app/api/parse-pdf/route.ts app/api/verify-pdf-provider/route.ts app/api/generate/tts/route.ts lib/server/resolve-model.ts lib/server/provider-config.ts

Also verified locally that server-configured MiniMax TTS succeeds when the client leaves the API key empty and echoes the server Base URL.