fix(speedtest): 让测速支持节点的 DialerProxyName 前置代理

[isdoge]

描述

问题：sublinkpro 内置测速调用 MihomoDelayTest/MihomoSpeedTest 时只 传节点原始 Link，不读 Node.DialerProxyName，导致配置了前置代理的
节点测速仍走直连，无法反映 dialer 实际效果。

修复：

• services/mihomo/mihomo.go: 新增 mockTunnel 实现 constant.Tunnel 与 proxydialer.Tunnel，新增 GetMihomoAdapterWithDialer 与内部 getMihomoAdapterWithContext；当传入 dialer 时构建 dialer 代理映射 并用 adapter.WithTunnelForAPI 注入 tunnel，proxyMap 写入 dialer-proxy 字段，使 hy2/trojan/vmess 等节点经 dialer 拨号。
• services/scheduler/speedtest_task.go: 延迟与速度两阶段在调用前 通过 models.GetNodeByName(n.DialerProxyName) 查询 dialer 节点， 取其 EffectiveName() 与 Link 传入测速函数。

兼容性：DialerProxyName 为空时行为与原来完全一致；GetMihomoAdapter
旧签名保留，node/sub.go、node/usage.go、services/unlock/orchestrator.go 等既有调用点无需改动。

Refs: 内部验证发现 speedtest_task.go 只传 n.Link 不带 DialerProxyName

---

关联 Issue

Fixes # （无对应 Issue）

---

更改类型

• 🐛 修复 Bug (Bug)
• ✨ 新功能 (Feature)
• 📝 文档更新 (Docs)
• 🎨 样式或界面改进 (UI)
• ♻️ 代码重构 (Refactor)
• ⚡ 性能优化 (Perf)
• 🔧 配置更改 (Config)
• 🧪 测试更新 (Test)

---

更改内容

• services/mihomo/mihomo.go：

  • 新增 mockTunnel 实现 constant.Tunnel 与 proxydialer.Tunnel 接口
  • 新增 GetMihomoAdapterWithDialer 与内部 getMihomoAdapterWithContext
  • 当传入 dialer 时构建 dialer 代理映射并用 adapter.WithTunnelForAPI 注入 tunnel，proxyMap 写入 dialer-proxy 字段
  • MihomoDelayTest 和 MihomoSpeedTest 新增 dialerName、dialerLink 参数

• services/scheduler/speedtest_task.go：

  • 延迟与速度两阶段在调用前通过 models.GetNodeByName(n.DialerProxyName) 查询 dialer 节点
  • 取其 EffectiveName() 与 Link 传入测速函数

---

截图

不适用

---

检查清单

• 我的代码遵循项目代码风格
• 后端检查已通过（本地无 go，需要 CI 验证）

  golangci-lint run
  go test ./...
  

• 前端改动已运行 yarn run lint（无前端改动）
• UI 改动已检查 light/dark 和响应式状态（无 UI 改动）
• 已按需补充或更新后端测试、注释和文档（已补充详细注释）
• 行为或契约变化时，已检查跨层同步（仅后端，无跨层）
• 本次更改不会引入安全漏洞（仅修复 dialer 支持，不涉及安全）

---

其他说明

注意：hy2（Hysteria2）节点 + dialer 组合测速仍会返回 503 快速失败，这是 mihomo 本身的限制（之前实验已证实），不是 sublinkpro 问题。TCP 系协议（trojan/vmess/socks5）经 dialer 测速正常。

兼容性：DialerProxyName 为空时行为与原来完全一致；GetMihomoAdapter 旧签名保留，node/sub.go、node/usage.go、services/unlock/orchestrator.go 等既有调用点无需改动。