Swap release workflows

[furkatgofurov7]

Currently, we have 2 functional (tested) release workflows in the repo:

1. "current" modular workflow: https://github.com/rancher/turtles/blob/main/.github/workflows/release.yml, where it has:

• release_build/ --> builds & pushes the image
• release_sign/ --> signs with Cosign
• release.yaml --> reusable workflow (build + sign)
• release-workflow.yaml --> the top-level release entrypoint (tag push or manual run, builds images to multiple registries, then does Helm chart packaging + release)

2. "new" single monolithic workflow https://github.com/rancher/turtles/blob/main/.github/workflows/release-v2.yaml, where it has:

• release job → builds and pushes per-architecture images (linux/amd64, linux/arm64) for both community (DockerHub) and prime (staging registry). Uses QEMU for cross-builds and retrieves all registry credentials from Vault.
• merge job → takes the per-architecture images, creates multi-arch manifests with docker buildx imagetools, and pushes them. For staging images, it also installs Cosign + slsactl, signs the multi-arch image, and generates/attests SLSA provenance.

Missing steps/design in "new" workflow that we need to borrow over from "current" workflow:

1. Helm chart packaging (required)
2. GitHub release publishing to the repo (required)
3. actions/setup-go (might need once we add 1 & 2) (most probably required)
4. cosign verify step after signing, which does not verify signing (optional?)
5. Single file instead of reusable workflow structure: composite actions + reusable workflows (completely optional IMO)

Once we have everything or more or less 1:1 between "current" & "new" workflow AND internal agreement on stopping to publish to (ghcr.io + prime registry, where latter will be taken care by Rancher Release Team in new workflow), we can swap release workflows.

Note: Post swap cleanup might be needed (once we are sure new workflows are working fine) but that can be tracked as a separate issue and follow-up.