Adds code signing to tagged windows builds

[rekhoff]

Note: This change requires the addition of new entries in the secrets to work properly. These should be added prior to this merging.

Description of Changes

• Add a tag-only Windows signing job that runs on a self-hosted signing runner.
  • This is an alternative/separate code-path just for the signing job. See Alternatives Considered for details.
• Skip the unsigned Windows matrix build on tags so signed artifacts are the only Windows release outputs.
• Sign spacetimedb-update.exe, spacetimedb-cli.exe, and spacetimedb-standalone.exe before packaging, then upload the signed artifacts as usual.

Alternatives Considered

Inline signing in the existing Windows packaging step. This was rejected because it would require all Windows builds (including non-tag builds) to run on the signing-capable runner or to install/signing tooling on GitHub-hosted runners. The chosen approach isolates signing to tag releases, avoids exposing credentials in standard builds, and keeps routine CI behavior unchanged.

API and ABI breaking changes

None

Expected complexity level and risk

2 – low risk. CI-only change that adds a new signing job and preserves existing artifact layout.

Testing

• None (Not running, workflow change only)

To fix this, explicitly scope down the GITHUB_TOKEN permissions used by this workflow to the minimum needed. Since the jobs only need to read repository contents (for actions/checkout) and do not modify GitHub resources, contents: read at the workflow or job level is sufficient.

The simplest, non‑disruptive fix is:

• Add a top‑level permissions: block just under name: in .github/workflows/package.yml, setting contents: read.
• This applies to all jobs (build-cli and build-cli-windows-signed) that don’t define their own permissions, so no further changes are necessary.

No extra imports, methods, or definitions are needed; this is purely a YAML configuration change in .github/workflows/package.yml.

In general, the fix is to explicitly declare a permissions block for the workflow or for individual jobs, limiting the GITHUB_TOKEN to the least privilege necessary. Here, the jobs only need to read repository contents (for actions/checkout) and then use external secrets for uploads; they do not create releases, write to issues, or push tags. Therefore, setting contents: read at the workflow root is sufficient and applies to all jobs that don’t override it.

The single best fix is to add a top-level permissions block near the top of .github/workflows/package.yml, alongside name and on, with contents: read. This keeps behavior unchanged for the workflow while ensuring the token can’t be used for unintended write operations. No imports or additional methods are needed, as this is purely a YAML configuration change.

Concretely:

• Edit .github/workflows/package.yml.
• Insert:

permissions:
  contents: read

between the existing name: Package SpacetimeDB CLI and the on: block (or anywhere at the root level, but that spot is conventional and clear).