feat(ai-video): video generation for custom providers on the job system

[DeJeune]

What this PR does

Before this PR:

• Cherry Studio had no video-generation pipeline. Aggregator providers (DMXAPI, PPIO, AiHubMix) could not generate video, and aiCore had no generateVideo runtime path.

After this PR:

• Adds end-to-end video generation for aggregator/custom providers, running on the async job system — mirroring the custom-provider image-generation pipeline from feat(ai-image): run custom-provider async image generation on the job system + fix image-model routing #16133.
• aiCore runtime: new generateVideo execution path (executor, plugin engine, runtime types/errors/index, provider extension wiring).
• Video transports (submit → poll → signed URL), resolved by videoTransportRegistry keyed on the resolved SDK provider id:
  • DMXAPI — HappyHorse/Vidu via /v1/responses, Hailuo via the 3-step REST flow.
  • PPIO — unified video API.
  • AiHubMix — Sora-compatible.
• Job system: videoGenerationJobHandler runs transports on the job system and rebuilds the exact transport after a restart from the persisted model id; videoGenerationModel defines the provider-agnostic transport contract; videoOptions maps scalar params (resolution / duration / ratio / seed / watermark / …) per provider.
• Wiring: AiService integration, new IPC channel, and preload bridge.
• provider-registry data: video-generation capability (enum + schema), new providers (FAL, Replicate, Kling AI), and video model entries.
• Tests: per-transport tests (DMXAPI, DMXAPI-Hailuo, PPIO, AiHubMix), generateVideo runtime test, videoOptions test, and AiService test additions.

Fixes #

Why we need it and why it was done in this way

The following tradeoffs were made:

• Reuses the existing async job system (same model as image generation feat(ai-image): run custom-provider async image generation on the job system + fix image-model routing #16133) so long-running submit/poll video jobs survive app restarts, rather than holding them in-memory on a single IPC call.
• Aggregator video runs exclusively on the job handler (submit/poll) with no in-SDK VideoModelV3 wrapper; native providers (Veo / Grok / Luma / Kling / Seedance / Wan) bypass this and resolve through provider.videoModel().

The following alternatives were considered:

• A synchronous in-SDK video model wrapper — rejected because aggregator video is inherently submit-then-poll and must be restart-resumable.

Links to places where the discussion took place: N/A

Breaking changes

None — additive (new capability, providers, models, and runtime path).

Special notes for your reviewer

• Opened as a draft / WIP (branch: video-generation-research). DMXAPI Hailuo transport and provider/model coverage are still being expanded.
• This builds directly on the custom-provider image-generation job pipeline (feat(ai-image): run custom-provider async image generation on the job system + fix image-model routing #16133); the transport/registry/handler structure intentionally mirrors resolveImageTransport / imageGenerationModel.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Branch: This PR targets the correct branch — main for active development, v1 for v1 maintenance fixes
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

Add video generation for custom/aggregator providers (DMXAPI, PPIO, AiHubMix) running on the async job system.