Run Windows S3 uploads from PowerShell

[gontzess]

Why

The shared release workflow now fails Windows MSI releases during S3 upload with SignatureDoesNotMatch after moving that path onto the Bash-based s3api put-object helper. The Docker/Public ECR hotfix is being picked up; this is a separate Windows artifact upload failure that blocks manifest publication and registry recording.

The Windows upload path also needs explicit native-command failure handling so an upload failure cannot be lost inside a loop.

What this changes

• Adds a Windows-native PowerShell S3 artifact uploader that keeps the existing immutable upload behavior: preflight existing objects by sha256 metadata, upload with PutObject plus If-None-Match: *, and fail if an existing object has different or missing sha256 metadata.
• Switches only the Windows artifact upload step to pwsh; macOS/Linux binary uploads continue using the existing Bash helper.
• Adds PowerShell coverage for artifact selection and fail-closed put-object errors, wired into make test when pwsh is available.

Validation

• make test
• make workflow-validate
• git diff --cached --check
• orch-cross-review --provider codex found no blocker; it noted the local pwsh skip as a low test-gate gap.
• HubSpot test release v0.0.10-test.1: https://github.com/ConductorOne/baton-hubspot/actions/runs/27040354513

The HubSpot test release passed end to end. The previously failing release / goreleaser-windows job passed Upload Windows artifacts to S3, then publish-release-manifest, verify-release, and record-registry-api all passed. Registry API shows ConductorOne/baton-hubspot v0.0.10-test.1 as VERSION_STATE_PUBLISHED with Windows ZIP/MSI assets, manifest/signature URLs, and image digests.

Note: local make test skipped the PowerShell test because pwsh is not installed on this machine; the live windows-latest release run exercised the PowerShell helper in the actual release path.

[jugonzalez12]

seems legit, powershell is the devil