fix: 修复任务并发被单引擎队列误钳制

[nightt5879]

close #367

修改内容

• 移除任务队列层面对 faster-whisper / FunASR / Qwen / FireRed 的整文件串行钳制，让文件级任务重新按“最大并发任务数”派发。
• 新增转写阶段串行锁，仅串行共享单 runtime 的 ASR 调用，避免多个 faster-whisper / sherpa 系转写同时占用同一 sidecar / worker。
• 纯翻译任务不再因为保留了 transcriptionEngine 配置而被误判为需要单线程执行；生成+翻译任务的音频提取和翻译阶段也可以继续并行。
• 补充并发判定和串行锁行为的单元测试。

根因

原来的调度器只要发现执行中或待派发队列里存在 faster-whisper / FunASR / Qwen / FireRed，就把整批任务的有效并发数降为 1。这个保护范围过大，导致用户即使设置并发数为 5，提取、翻译以及 translateOnly 场景也只能一个个处理。

验证

• npm run test:engines
• npm run check:i18n
• npm run build

[vercel]

@nightt5879 is attempting to deploy a commit to the buxuku's projects Team on Vercel.

A member of the Team first needs to authorize it.

[buxuku]

感谢你的 PR！根因分析完全正确——问题就出在调度器把受限引擎的整个任务队列钳成了串行，「取消队列级钳制、只让转写阶段互斥」的思路也和我们的方案一致，分析很专业。

不巧的是我这两天刚好在 feat/cloud-asr-providers 分支上处理了同一个问题（7ea44f3120fd53f5403ab5139512787422b1c3fb），当时没在 issue 上标记「正在处理」，让你做了重复劳动，非常抱歉 🙏

分支上的实现与本 PR 的主要差异：

1. 互斥按「执行体」分组而非一把全局锁——faster-whisper（Python sidecar）与 funasr/qwen/fireRedAsr（sherpa worker）是独立运行时，可互相并行，仅组内串行；
2. 排队等待支持取消（AbortSignal），任务取消立即出队，不会白等锁；
3. 顺带处理了云端引擎服务商级限流、取消句柄按项目隔离等相邻问题。

所以打算采用分支上的实现，随下个版本发布，届时会关闭本 PR 和 #367。再次感谢你的贡献和清晰的分析，欢迎发版后帮忙验证效果！