* ci(release): run the SignPath path on GitHub-hosted runners
SignPath's open-source plan accepts a signing request only when every job leading up to it ran on a GitHub-hosted runner, and tsf, server and package all ran on the self-hosted release machine. With WINDOWS_SIGNING_PROVIDER=signpath they now run on windows-2025, restoring vcpkg binaries and (for the Server) sccache the way ci.yml does; the certificate path keeps the self-hosted runner unchanged.
The org secret holding the SignPath API token is SIGNPATH_TOKEN, so the workflow and detect-release-signing.ps1 read that name instead of SIGNPATH_API_TOKEN.
AGENTS.md lists what SignPath needs configured, and the code signing policy records the accepted application and the hosted-runner rule.
* fix(ci): let the SignPath action read the run's artifacts
* fix(installer): drop authenticode-sign attributes SignPath Foundation rejects
* fix(ci): fail the hosted SignPath release before signatures are spent
- Probe ISCC with WizardStyle=modern dynamic and run that probe at the start of the hosted package job, so an image ISCC older than 6.6 fails before the payload signing request instead of after it.
- Verify the TSF vcpkg root before installing into it or saving its archives under the -complete key.
- Check the Server job's C:\vcpkg override against the vcpkg the hosted image puts on PATH.
- Code signing policy: drop the stale "once approved" wording and state that the hosted-runner rule applies to SignPath-signed releases.
* docs: list only the configured SignPath approver
---------
Co-authored-by: fanlusky <1730976608@qq.com>
