feat(local-integration): 新增模块本地 HTTP 总线

[liruilong]

摘要

• 新增 ChillPatcher.Module.LocalIntegration 模块，提供可配置的本地 HTTP 总线，用于可信本地工具与第三方模块集成。
• 在 ChillPatcher.SDK 中新增 ILocalIntegrationHandler，模块程序集可以通过实现该接口注册自己的本地路由。
• 总线只负责监听、Token 鉴权、路由匹配和把请求派发回 Unity 主线程；本 PR 不内置 AIChat、TTS、番茄钟或环境控制等具体业务端点。
• 顺带将 SaveProfileService 中的字符串匹配改为 net472 可用的 IndexOf(..., StringComparison)，确保该分支可独立构建。

验证

• dotnet build ChillPatcher.Module.LocalIntegration\ChillPatcher.Module.LocalIntegration.csproj -c Debug -p:SteamLibraryRoot=D:\Steam

说明

• 默认监听 127.0.0.1:18792，除非用户显式修改 Host，否则不会开放到局域网。
• 配置 Token 后，请求需要使用 Authorization: Bearer <token> 或 X-ChillPatcher-Token。
• 具体集成能力建议由第三方模块实现 ILocalIntegrationHandler 后自行注册，避免主仓绑定特定本地工作流。

[BeyondtheApex]

这是啥?

[BeyondtheApex]

你可能得更新一下了
我重构开始的时候好像没有合并
现在开始冲突了

[liruilong]

我想先确认一下现在该项目的方向。

从这波重构看，项目主轴好像已经从单纯的 ChillPatcher，转向了一个更通用的 OmniMixPlayer 独立音频平台：

• OmniMixPlayer.Backend 负责播放、队列、音源模块、API
• OmniMixPlayer modules 负责 Netease / QQMusic / Bilibili / Spotify / LocalFolder 这些媒体源
• ChillPatcher 和 FH6 bridge 更像是消费 OmniMixPlayer 音频能力的两个 game integrations
• 原来 ChillPatcher 侧的 ModuleSystem / MusicRegistry / ModuleLoader 也基本被移到 Backend 或通过 IPC bridge 替代了

这个方向本身我能理解，也挺有价值。
但我想确认一下：项目后续的主轴是不是准备往 OmniMixPlayer 这个独立音频平台靠？

如果是这样，我也想确认另一个问题：ChillPatcher 作为 Chill with You 的游戏侧 Mod，后续还会作为一等项目继续维护吗？

因为我们这边在做的扩展主要不是音源流媒体 module，而是 Chill 游戏侧能力模块，例如：

• TTS / 语音播报
• 番茄钟
• 环境 / 场景 / 环境音控制
• 角色动作 / 字幕
• StreamDeck / 本地脚本入口

详细见：
https://github.com/Codes39/chillpatcher-modules
https://github.com/Codes39/chillpatcher-streamdeck

这些能力需要运行在 Unity / BepInEx 游戏进程里，需要 ChillPatcher 自己保留一个 module 加载入口。它们不太适合放进 OmniMixPlayer/modules，因为那套模块系统更像是 media module system。

所以我想先对齐一下方向：

1. 这个仓库后续的主项目是 OmniMixPlayer，还是 ChillPatcher？
2. ChillPatcher 后续是否还会维护独立的第三方 module 入口？
3. FH6 bridge、ChillPatcher、OmniMixPlayer 这三者你希望是一个 monorepo 下的三个独立边界，还是都归到 OmniMixPlayer 的平台体系里？

如果主轴已经确定要转向 OmniMixPlayer，我这边也可以按这个方向调整预期；但如果 ChillPatcher 还会继续作为独立游戏侧 Mod 维护，那我建议我们先把 ChillPatcher 的模块边界保留下来，再处理这个 PR 的冲突。