fix: 适配新版客户端，修复 nativeFetch 导致的请求参数错误

[Inkarro]

fix #1676 UnblockNeteaseMusic/luci-app-unblockneteasemusic#337

最新版的网易云音乐 Windows 客户端在启用 UNM 代理后，许多页面（如我喜欢的音乐、用户详情页等）无法加载，并提示 "请求参数错误"。

经过分析，定位到问题由两个主要变更导致：

1. 新的 API Host： 新版客户端开始使用 interfacepc.music.163.com 作为其主要的 API Host，而不再是旧版的 interface.music.163.com。这导致 UNM 无法 Hook 到新版客户端的请求。
2. 引入 nativeFetch： 新版客户端在 Windows 平台下引入了 o.Network.useNativeFetch 逻辑。
   • 当此项为 true 时，客户端会使用原生的网络请求方法，而非浏览器的 fetch API。
   • 当此项为 false (或被强制修改为 false) 时，客户端回退到使用浏览器 fetch，此时（在添加新 Host 后）UNM 可以正常工作。

根本原因：

进一步排查发现，当 nativeFetch 开启时，客户端所新增的 nativeFetch 似乎无法正确处理 GZIP 压缩的响应。

而 UNM 此前会无条件为所有经过代理的请求添加 Accept-Encoding: gzip, deflate 请求头。

• 对于 UNM 明确 Hook 的 API（如 api/song/enhance/player/url/v1），UNM 自身会处理响应体的 GZIP，因此播放功能正常。
• 对于 UNM 未 Hook 的 API（如获取登录信息、用户详情页等），UNM 只是透传了请求。它添加了 Accept-Encoding 头，导致服务端返回了 GZIP 压缩数据，而客户端的 nativeFetch 无法解析，最终导致数据加载失败，并报错 "请求参数错误"（可能是因为解析失败导致后续逻辑中确实缺少了参数，如我喜欢的音乐提示该错误是因为参数中传递了 id: undefined）。

此 PR 采用了两项关键修改：

1. 添加新 Host： 将 interfacepc.music.163.com 添加到 Hook 列表，确保 UNM 能够拦截新版客户端的请求。
2. 条件性添加 Accept-Encoding： 仅当 UNM 收到的原始请求头中 已存在 Accept-Encoding 字段时，才将其覆盖设置为 Accept-Encoding: gzip, deflate。

修改后，无论 nativeFetch 开启与否，新旧版客户端均可正常工作。

[1715173329]

已合并，再次感谢您的 PR！