Sign release artifacts when publishing

[glopesdev]

Smart App Control now blocks unsigned executables with no option to "run anyway", so an unsigned installer is unusable on some modern releases of Windows 11. Here we sign executable release artifacts with the Bonsai Foundation code-signing certificate, through the reusable bonsai-rx/sign action over SSL.com eSigner cloud signing.

Signing order

Signatures are applied in dependency order, because each later artifact carries a copy of an earlier one.

• The repacked Bonsai.exe is signed straight after the repack step. One signature there covers three consumers: the copy packed into the Bonsai package, the copy in Bonsai.zip, and the copy the MSI installs. Those three copies have to stay identical, since a local environment verifies whichever copy it finds against a single recorded checksum per version.
• The MSI is signed after it is built and before the bundle is built, since the bundle embeds it and records its hash.
• The bundle takes two signatures. A Burn bundle cannot be signed in one pass, because bundling rebuilds and reattaches the engine, so insignia detaches the engine, the engine is signed, insignia reattaches it, and the bundle is signed last.

CodeSignTool applies an RFC 3161 timestamp to each signature.

Where the signing runs

The signature has to be applied while the build is still running, before the package, the portable zip and the MSI take their copies, so build-and-test now carries a conditional environment scoped to the single build matrix target that signs. On a publishing run the target that creates the installer runs in PublicRelease, and every other target runs in no environment at all. The signing credentials therefore live as environment secrets and are only reachable from an approved deployment, rather than being available to every run on every branch.

Releases now request two approvals for that environment, one for the signed installer target and the existing one for the NuGet push.

Release ordering

The push to NuGet.org is the only step of a release that cannot be undone. A version can be deleted from nuget.org but never published again, whereas release assets can be replaced, the latest tag can be moved, the milestone can be reopened and the documentation site can be redeployed. So the push now waits for publish-github, and inside its own job it runs after the NuGet.org login and after the documentation dispatch.

The effect is that an expired documentation token now fails a job that has done nothing irreversible, and a re-run after replacing the token completes the release. Previously the same failure would leave packages published while the tag move, the version bump and the milestone close were all skipped.

This also narrows what #2635 has to solve. With the documentation dispatch now ahead of the push, an expired documentation token fails the release before anything irreversible has happened, so re-running the failed job becomes a safe recovery rather than a second attempt at an already completed push, which was the objection when re-running was discussed there. The only release credential whose failure can still occur after the irreversible step is the deploy key used by finish-up-release, and recovering from that by hand means moving a tag, bumping a version and closing a milestone rather than repairing a partially published release.

Closes #2641