What does this implement/fix? Explain your changes.

This PR fixes a critical issue in the release workflow where version numbers were being "skipped" due to multiple workflow runs creating duplicate version bump commits without corresponding GitHub releases and tags.

Problem

The release workflow was creating version sequences like:

• v2.3.3 ✅ (released)
• v2.3.4 ❌ (commit created, no tag/release)
• v2.3.5 ❌ (commit created, no tag/release)
• v2.3.6 ✅ (released)

Root Cause

1. Multiple workflow runs: The workflow could run multiple times for the same event, creating duplicate version bump commits
2. Failed release creation: The workflow would create version bump commits but sometimes fail to create the actual GitHub release/tag
3. No version existence checking: The workflow didn't check if a version already existed before attempting to bump it
4. Non-atomic release process: The workflow used continue-on-error: true which masked failures

Solution Implemented

1. Added Concurrency Control: Prevents multiple releases from running simultaneously
2. Added Version Existence Check: Checks if version already exists before bumping
3. Made Release Creation Atomic: Removed continue-on-error: true and added proper error handling
4. Enhanced Logging & Debugging: Added comprehensive debug information
5. Improved Job Outputs: Added version existence tracking

Key Changes

• Added concurrency control to prevent duplicate workflow runs
• Added Check if version already exists step that skips release if version already has a tag
• Made all release steps conditional on version not already existing
• Removed continue-on-error: true from GitHub release creation
• Added comprehensive debug logging and release summary
• Updated job outputs to handle both new and existing versions

Does this close any currently open issues?

closes #3425

Any other comments?

Testing Results

• ✅ Version existence check works correctly
• ✅ Cross-platform grep syntax tested
• ✅ Skip logic validated with existing tags
• ✅ No linting errors in the workflow file

Expected Behavior After Fix

1. For existing versions: Workflow will detect the version already exists and skip gracefully
2. For new versions: Workflow will proceed normally with full release process
3. For duplicate runs: Concurrency control will cancel previous runs
4. For debugging: Enhanced logging will show exactly what happened

Impact

• High: Fixes critical release workflow reliability issues
• Breaking: No breaking changes to the release process
• Backward Compatible: Existing releases and tags remain unaffected

This fix should ensure consistent version progression without gaps and prevents orphaned version bump commits.