[DEVOPS] Make releases manual

### Make Releases Manual (with Controlled Trigger)

## Problem

Currently, merging a Pull Request into `pre-release` or `main` automatically triggers a full release after the build completes.

This automated approach has several drawbacks:
- No control over **when** a release actually happens
- Packages can be released unintentionally (even if the merge was only for testing or hotfix validation)
- Lack of final human approval before publishing to users/customers
- Increased risk of releasing incomplete or unwanted versions

This is not considered a best practice for production releases.

## Proposed Solution

Make the **release process manual** while keeping version bumping automated.

### Key Changes:

- Use `workflow_dispatch` to trigger releases manually instead of automatic triggers on merge
- Create a dedicated **Release Pipeline** that allows users to:
- Select the branch (`main` or `pre-release`)
- Choose a pre-built package/version that is ready to be published
- Trigger the release with a single button click

### Implementation Details:

- Switch release workflow to `workflow_dispatch` for manual triggering
- Add **Environment Protection** in GitHub Actions:
- Create a new environment called `production`
- Require reviewer approval before the release can proceed
- Add workflow inputs for better control:
- Version number (pre-filled or selectable)
- Release notes / changelog

## Nice to Have

- Add a checkbox option: **"Also publish Helm chart for this version"**
- When checked, the Helm chart will be published automatically with the **exact same version** as the package
- This helps enforce synchronization between application package and Helm chart versions

## Benefits

- Full control over release timing
- Human approval gate before publishing
- Reduced risk of accidental releases
- Easier coordination with team and stakeholders
- Better alignment between package and Helm versions

---

### Acceptance Criteria

- [ ] Release is no longer triggered automatically on merge to `main` or `pre-release`
- [ ] Release workflow uses `workflow_dispatch` with manual trigger
- [ ] A `production` environment is created with required approver review
- [ ] Users can select branch and version before releasing
- [ ] Optional checkbox to publish Helm chart for the same version
- [ ] Clear success/failure notifications after release

Start by locating the existing release workflow and reviewing its triggers and publishing steps. Change the release path to a manually dispatched workflow with branch, version, changelog, and Helm publication inputs, then verify production approval and success/failure notifications against the acceptance criteria.

Written by the indexing model from the issue text.