[Bug]aiocqhttp 适配器未处理 record 消息的裸文件名，导致语音转文字失败

[NoFizz]

What happened / 发生了什么

使用 LuckyLilliaBot（LLOneBot）作为 QQ 协议端时，发送语音消息会导致语音转文字（STT）失败。
根本原因是 aiocqhttp_platform_adapter.py 中 record 类型消息走的是通用 else 分支，直接用协议端返回的裸文件名（如 0d2bb1468a87d64414f8e563cc61c33c.amr）创建 Record 组件。该文件在本地不存在，MediaResolver 创建了一个几乎为空的文件（144 字节），MiMo STT 的 WAV 校验失败并抛出异常。
值得注意的是，file 类型消息已有专门的处理逻辑（通过 get_group_file_url API 获取真实链接），但 record 类型缺少类似的处理。

Reproduce / 如何复现？

1. 配置 MiMo STT 作为语音转文字提供商
2. 在 QQ 中向机器人发送一条语音消息
3. 观察日志，出现 MiMoAPIError: Audio for MiMo STT could not be converted to WAV 错误

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

AstrBot 启动器部署
AstrBot v4.26.5
LuckyLilliaBot v8.0.7
MiMo STT 提供商（模型mimo-v2.5-asr）

OS

Windows

Logs / 报错日志

[2026-07-09 19:15:27.605] [Core]
[INFO]
[core.event_bus:74]: [阿紫（独享型）] [阿紫(aiocqhttp)] 知野/1589165102: [ComponentType.Record]
[2026-07-09 19:15:28.038] [Core]
[ERRO]
[v4.26.5] [preprocess_stage.stage:201]: Traceback (most recent call last):
File "astrbot\core\pipeline\preprocess_stage\stage.py", line 189, in _stt_record
result = await stt_provider.get_text(audio_url=path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "astrbot\core\provider\sources\mimo_stt_api_source.py", line 77, in get_text
audio_data_url, cleanup_paths = await prepare_audio_input(audio_url)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "astrbot\core\provider\sources\mimo_api_common.py", line 80, in prepare_audio_input
_validate_wav_payload(audio_data.base64_data, audio_source)
File "astrbot\core\provider\sources\mimo_api_common.py", line 118, in _validate_wav_payload
raise MiMoAPIError(
astrbot.core.provider.sources.mimo_api_common.MiMoAPIError: Audio for MiMo STT could not be converted to WAV (unrecognized audio bytes): local media path name='media_audio_cf72f3a4fcd344f2ac7b406016997d3c.wav' len=144
[2026-07-09 19:15:28.038] [Core]
[ERRO]
[v4.26.5] [preprocess_stage.stage:203]: 语音转文本失败: Audio for MiMo STT could not be converted to WAV (unrecognized audio bytes): local media path name='media_audio_cf72f3a4fcd344f2ac7b406016997d3c.wav' len=144

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

@NoFizz 确认了这个问题。record 类型消息在 aiocqhttp 适配器中走的是通用 else 分支，直接用 **m["data"] 实例化 Record 组件，没有像 file 类型那样调用 get_group_file_url / get_private_file_url 来获取实际下载链接 [1]。

对比来看，file 类型有完整的平台检测逻辑（区分 Lagrange 直接提供 URL vs Napcat 需要 API 调用）[2]，但 record 完全缺少等价处理。

相关背景：

• 这与 #9113 报告的 MiMo STT 问题密切相关 [3]，maintainer 在 #9153 中确认该问题存在且修复尚未发版 [4]。
• 此前 PR fix: cannot resolve voice when using aiocqhttp adapter #8523 改善了 Record 组件的源解析逻辑（优先使用 url 字段），PR fix: prefer record url for audio downloads #7726 也做了类似优化 [5] [6]，但适配器层面仍未添加类似 get_record 的 API 调用来主动获取音频 URL。

LLOneBot 的情况： 从 #9153 中另一位用户的原始消息段可以看到，OneBot 实现返回的 record 数据中实际上包含了 url 和 path 字段，但当前代码没有正确利用这些字段（或某些实现如 LLOneBot 可能只提供 file 裸文件名）。修复方向应该是在适配器中为 record 类型添加专门处理：优先使用 url 字段，如果不存在则尝试调用 get_record API 获取可下载链接。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.