build: 仅 ECNU 发行版生成 GitHub 更新清单

[wf0229]

第三方机构发行版没有对应的 ECNU/<发行版名> GitHub 仓库，但 Windows 稳定版构建会调用只接受 EduWork 两版身份的清单生成器，导致发布阶段失败。

本 PR 仅为 EduWork、EduWork-ECNU 生成 ECNU GitHub 更新清单。其他机构版仍输出安装包、发布回执和发布说明，供机构部署自己的更新源。

修改覆盖当前 Node 构建入口 scripts/lib/windows-stages.mjs，以及保留的两个 PowerShell 入口 ci-pinned-dsh-desktop.ps1、ci-eduwork-windows-release.ps1。清单生成器的版本、发行身份和产物校验保持不变。

验证：

• 在实际 Node publish 阶段用合成产物覆盖 npm / pinned-source 两种装配、EduWork / EduWork-ECNU / 第三方机构三种发行版，以及稳定 / Alpha / 开发版三种情况；修复前两个机构稳定版用例失败，修复后通过。
• 发布与附件校验相关测试共 42 项通过；两份 PowerShell 语法检查通过；源码回执审计无错误、无警告。
• 本地验证为发布阶段回归，没有重新构建完整桌面安装包。

保留 @wf0229 的原始提交，并适配当前 main 的构建入口。

[freedomkk-qfeng]

感谢提出第三方机构发行版的更新源问题。复核这版修改（88d12e2）后，发现新增条件目前不会改变行为。

同一脚本前面已经把 $name 固定为二选一：

$name = if ($CoreRoot -eq $EditionRoot) { 'EduWork' } else { 'EduWork-ECNU' }

因此新增的 $name -in @('EduWork','EduWork-ECNU') 永远成立。其他机构走到这条路径时，名称仍会被当成 EduWork-ECNU，更新源也仍然使用 ECNU/$name。另外，清单生成器本身还校验这两种发行身份，单独补这个条件无法支持第三种发行版。

建议讨论一下把调整放到发行构建配置层：

• 明确声明产品/产物名称及更新来源，不再根据目录关系推断学校版身份、根据名称拼出 GitHub 仓库。
• 公版和 ECNU 保持各自现有的仓库与更新契约；其他机构可明确指定自己的 GitHub 仓库、自建源或关闭更新。
• 只有声明使用 GitHub 更新源时才生成对应清单；身份、资产名称、大小和哈希检查继续保留。未支持或不一致的配置应给出明确错误。
• 补一个第三方机构构建计划的回归，确认不会再生成指向 ECNU 仓库的清单。

这个方向应能限制在构建配置及相关脚本，不需要重写 CI 工作流。也想确认一下：你遇到问题时是否还有配套的发行名称改动未包含在本 PR？若有，可以一起看最小的修复范围。

[wf0229]

感谢细致的复核，判断是对的：这个 PR 漏带了一个配套改动，单独合入确实不起作用。

在我们的分支里，$name 不是按目录关系二选一，而是由另一个提交从发行清单读取（Resolve-EduworkReleaseName $selectedDistribution.id $selectedDistribution.release）。对我们的发行版（词元工坊 / TokenWorks）解析出来是 TokenWorks，所以这里的条件为假，不会生成指向 ECNU/... 的清单。那个配套提交改动了 6 个文件（assemble-eduwork-web.ps1、assemble-windows.ps1、assemble-macos.ps1、审计脚本等），当时没有一并拆出来。

我们的实际情况可以作为第三方机构的参考：

• 更新源是自建的静态站点（Ed25519 签名的 Windows 清单 + Sparkle appcast），不使用 GitHub Releases；
• 构建时只需要「不生成 GitHub 清单」，其余身份、资产名称、哈希检查都希望保留。

非常赞同你提的方向：由发行构建配置显式声明产品名称和更新来源（GitHub 仓库 / 自建源 / 关闭），只有声明 GitHub 时才生成清单，并补第三方机构的回归。这比按名称白名单判断稳妥得多。

考虑到这需要统一调整发行配置层，交给你们按这个设计实现会更合适。我们这边目前的做法能正常工作，等上游实现后会迁移过去。如果需要我们提供脱敏的发行清单做回归用例，随时说。这个 PR 你们觉得不再需要的话可以直接关闭。