fix(ci): sign Windows binary via Cloud KMS provider

The Windows release job hung indefinitely on the "Sign Windows binary with signtool" step. The step used `signtool /a`, which auto-selects a certificate from the Windows certificate store, but the self-hosted runner's signing key is a Sectigo EV certificate whose private key lives in Google Cloud KMS. `/a` cannot use that key non-interactively and blocked on a credential prompt that never gets answered on the headless runner.

Add scripts/sign-windows.ps1, which signs through the explicit Google Cloud KMS provider (`signtool ... /csp /kc /f /ac`), mirroring the proven approach backend.ai-go uses on the same self-hosted runner. The release workflow now invokes this script instead of the inline `/a` command.

Because all-smi is a public repository, no certificate paths or KMS key identifiers are committed: the script reads them from environment variables injected from repository secrets (WINDOWS_SIGN_CERT_PATH, WINDOWS_SIGN_CA_CERT_PATH, WINDOWS_SIGN_KEY_CONTAINER), and only non-sensitive values (signtool path, provider name, timestamp URL) are defaulted. Missing secrets now fail fast with a clear error instead of hanging.