Support Stable, Beta, and Alpha update channels

[xyzuanli]

提交前确认

• 我已搜索现有 issue
• 本 issue 仅包含一个功能提议
• 本提议与关系图无关

该功能将解决什么问题？

思源笔记版本迭代速度较快，需要为愿意参与预发布测试的用户提供明确的更新通道，让更多用户在实际使用场景中帮助验证新版本，并尽量在正式发布前发现影响使用的问题。

描述预期结果或建议方案

在设置 - 关于 - 更新通道中提供以下选项：

• Stable：仅接收正式版。
• Beta：接收正式版、RC 和 Beta。
• Alpha：接收正式版、RC、Beta 和 Alpha。

已确认的行为

• 默认使用 Stable；现有用户及预发布版本用户升级后也默认使用 Stable。
• 更新通道是应用级全局设置，不跟随工作空间。
• 切换通道后只允许升级，不自动降级到低于当前版本的版本。
• 废除原有 Insider 机制。
• Beta 和 Alpha 通道直接查询 GitHub Release，不依赖社区服务器；界面中明确提示测试通道需要能够访问 GitHub。
• 自动更新仅使用与当前操作系统及架构完全匹配的安装资产。
• 优先使用 GitHub Release Asset 提供的 SHA-256 摘要，缺失时回退到 SHA256SUMS.txt。
• 缺少当前平台资产或可信校验摘要时，仅提示存在新版本并提供 GitHub Release 链接，不自动下载安装。

发布与摘要校验

预发布工作流先创建 Draft Release，生成并上传 SHA256SUMS.txt 及全部安装资产，然后逐一比较 GitHub 返回的远端摘要与本地摘要；只有全部资产上传完成且摘要一致时才公开 Release。校验失败时 Release 保持 Draft。

其他信息

测试通道用于能够正常访问 GitHub、愿意帮助验证预发布版本并通过 GitHub 反馈问题的用户。

[TCOTC]

我的想法是测试通道直连 GitHub，不在服务端维护，仅供连得上 GitHub 的用户测试

[xyzuanli]

我的想法是测试通道直连 GitHub，不在服务端维护，仅供连得上 GitHub 的用户测试

也行，不是所有人都盯着github，这样确实能多点人，但问题是如果只提供直连那肯定还会有用户问为什么测试通道下不了

[TCOTC]

一般来说测试出现问题建议直接在 GitHub 发 issue，所以只提供给能连 GitHub 的用户更好。至于连不上的用户，可以加文案说明一下情况。

[xyzuanli]

感觉在链滴开个测试专区挺好的，不过决定了直连也行

[88250]

已按确认方案完成改动，主要包括：

• 在设置 - 关于 - 更新通道中新增 Stable、Beta、Alpha 三个应用级全局更新通道，默认使用 Stable。
• Stable 仅接收正式版；Beta 接收正式版、RC 和 Beta；Alpha 接收正式版、RC、Beta 和 Alpha。
• Beta 和 Alpha 直接查询 GitHub Release，并在设置中提示测试通道需要能够访问 GitHub。
• 废除原有 Insider 机制，包括相关配置和界面标识。
• 保留版本比较保护，切换通道不会触发降级。
• 自动更新仅匹配当前操作系统和架构的准确安装资产；缺少对应资产或可信摘要时，仅提示存在新版本并提供 GitHub Release 链接，不自动下载安装。
• 优先使用 GitHub Release Asset 提供的 SHA-256 摘要，缺失时回退到 SHA256SUMS.txt；下载完成后再次校验本地文件，校验失败时删除安装包。
• 预发布流程先创建 Draft Release，生成并校验 SHA256SUMS.txt，确认所有远端资产上传完成且摘要一致后再公开 Release。