fix: 修正 UAC 链接顺序及原生 ALSA 启动恢复

[mofeng-git]

针对 #291 报告的 DWC3 UAC 麦克风透传无法启动、界面停留在等待目标机的问题，保留 One-KVM 内部的原生 ALSA 实现，修正 USB 功能链接顺序、PCM 启动和恢复逻辑。复用现有 alsa/libasound，不引入 aplay、子进程管道、后台线程或额外音频队列。

• ConfigFS 链接按功能注册顺序重建，保持 UAC 优先；链接重建失败时中止 UDC 绑定。
• 请求 1024-frame period / 32768-frame buffer，以实际协商容量设置启动阈值并预填静音；预填完成后仍处于 Prepared 时显式启动。
• 通过 PCM 消费进度判断目标状态，检测到消费后保留正在运行的流；正确推进短写偏移，EAGAIN 时立即返回。
• XRUN/挂起后重置并重新探测；输入中断超过 5 秒后在恢复输入时重开 PCM。保留 stop()/会话释放同步关闭设备的保证。

验证：在现有开发工作区运行 cargo test --offline --target x86_64-unknown-linux-gnu --lib audio::uac::playback::tests（10 个通过）及 cargo test --offline --target x86_64-unknown-linux-gnu --lib otg::manager::tests（4 个通过），覆盖短写、设备无空间、消费进度、原生 PCM 启动/恢复、停止关闭、空闲恢复及链接顺序/失败路径。原生 PCM 测试使用 ALSA null 设备。两处修改文件在 dev 与本 PR 的 main 基线完全相同；格式检查及 git diff --check 通过。

2026-09-10 实机验证：RK3588 BlueBerry（5.10.110 #68、libasound 1.2.4）+ Windows USB 音频接收端。独立测试实例创建 UAC1 + 4 HID + MSD，使用 DWC3 ep2in 等时端点。原生非阻塞 PCM 成功进入 RUNNING，实际协商为 48 kHz 双声道 S16_LE、period 1024、buffer 16384；未出现 EPIPE 启动失败。

完整链路 WebSocket PCM → One-KVM 原生 ALSA → USB → Windows 录音 通过：首次和恢复后各录得 6 秒，频率分析确认左声道 440 Hz、右声道 880 Hz。目标端停止/恢复录音时状态按预期经历 waiting → active → stalled → active。独占会话返回 409、输入空闲超过 5 秒后重开 PCM、会话关闭释放 PCM、新会话重新打开也通过。录音首个测试信号在开始后约 370–375 ms 出现，包含启动缓冲和主机采集，不能视为精确的端到端延迟。

Gadget 删除重建的实机回归仍未完成：预先进行的临时 Gadget 能力探测触发了旧厂商内核的 android_setup → __raw_spin_lock_irqsave panic（当时 PR 程序尚未运行）。崩溃与 2023 年 Rockchip configfs.c 中首个 Gadget 删除后全局 android_device 指针失效的缺陷吻合；确切厂商源码版本未取得。重启后首个 Gadget 的上述播放测试通过；没有重复执行会触发该问题的删除重建测试，也没有修改内核。测试结束已停止独立实例并重启恢复环境，原服务程序和配置保持不变。

较大缓冲作为兼容性起点，会增加音频延迟，后续可根据实机结果调优。空闲处理发生在恢复输入时，不是后台定时关闭。