fix: Prevent Windows signing service caching stale installers

[anchapin]

Description

This PR fixes a critical issue where the Windows signing step was receiving cached (stale) artifacts from the signing service. This occurred because the signing request used a static filename key (installer_to_sign.zip) in S3. If a previous build's artifacts remained, the signing client would pick them up instead of the new binary.

Fixes

1. Unique Keys: Updated the signing step to append the unique github.sha to the zip filename (e.g., installer_to_sign_<SHA>.zip). This forces the signing service to use a fresh S3 key for every build, bypassing any cache.
2. Safety Verification: Added a post-signing check to verify the extracted executable matches the expected filename.
3. Auto-Correction: If the signing service were to still return a mismatched filename (unlikely with fix OpenStudio App, Results Tab - In some instances a simulation will complete but no results will show #1, but possible if the service logic behaves unexpectedly), the workflow now renames the artifact to match the correct version, preventing the distribution of mislabeled binaries.

Testing

Verified that the signing client uses the filename to construct S3 keys. The unique filename ensures isolation between builds.