Adopt RFC 0018 release branch naming (release-X.Y) across all repos

## Summary

[RFC 0018](https://github.com/Kuadrant/architecture/blob/main/rfcs/0018-release-branch-naming.md) standardizes release branch naming to `release-X.Y` (no `v` prefix, minor-level only) across all Kuadrant repos. This issue tracks the migration.

**Strategy**: migrate the current 1.4 release line first, then validate with a 1.4.4 patch release before 1.5. This tests the entire pipeline on a low-stakes patch release.

## Phase 1: Add new patterns alongside old ones (PRs to `main`)

One PR per repo. **Add** new branch patterns alongside existing ones (don't replace yet). Update branch creation logic to produce `release-X.Y`. Update release scripts and docs. Merge all before any branch renaming.

> **Why dual patterns?** Three repos (kuadrant-operator, wasm-shim, developer-portal-controller) have workflows that trigger on PR merge to release branches. If we replace `release-v[0-9]+.[0-9]+` with `release-[0-9]+.[0-9]+` before renaming branches, any PR merged to the old branch name between Phase 1 and Phase 2 won't trigger the release workflow. Dual patterns eliminate this gap and make rollback trivial (just recreate the old branch — both patterns still match).

### kuadrant-operator
- [x] `.github/workflows/test.yaml:6` — `release-v*` → `release-*`
- [x] `.github/workflows/release-operator.yaml:8` — add `'release-[0-9]+.[0-9]+'` alongside existing `'release-v[0-9]+.[0-9]+'`
- [x] `.github/workflows/automated-release.yaml:75` — `release-v$(echo...` → `release-$(echo...` (branch construction)
- [x] `.github/workflows/automated-release.yaml:128` — `release-v${{...}}` → `release-${{...}}` (PR head branch)
- [x] `utils/release/load_github_envvar.sh:9` — sed extracts `v1.4` from tag producing `release-v1.4`; needs to strip the `v` to produce `release-1.4` (**note**: this file runs from the release branch, not main — the fix lands on the release branch via the 1.4.4 release prep PR in Phase 3)
- [x] `RELEASE.md` — 8 occurrences of `release-v`
- [x] `doc/overviews/helm-charts-release-process.md` — 5 references to `release-v{MAJOR.MINOR}` and `release-v{FULL_VERSION}`

### authorino-operator

> **Granularity change**: this repo currently creates a new branch per patch release (e.g., `release-v0.24.0`, `release-v0.24.1`). Under RFC 0018, one branch per minor (`release-0.24`) — patches are new tags on the same branch. The workflow needs to: (1) compute the minor-only branch name from the full version input, (2) check if the branch exists before creating, (3) use the minor-only name for push and target_commitish.

- [x] `.github/workflows/release.yaml:44` — `startsWith(..., 'release-v')` → `startsWith(..., 'release-')`
- [x] `.github/workflows/release.yaml:46` — branch creation: derive `release-X.Y` from version input (e.g., `release-$(echo "$VERSION" | sed 's/\.[0-9]*$//')`)
- [x] `.github/workflows/release.yaml:59` — `git push origin release-v${{...}}` → push to the derived minor-only branch name
- [x] `.github/workflows/release.yaml:67` — `target_commitish: release-v${{...}}` → use the derived minor-only branch name
- [x] `RELEASE.md:82` — 1 historical reference

### limitador-operator

> **Same granularity change as authorino-operator.** Uses `stefanzweifel/git-auto-commit-action` with `create_branch: true` — the `branch:` field must change to the minor-only name.

- [x] `.github/workflows/release.yaml:42` — `startsWith(inputs.gitRef, 'release-v')` → `startsWith(inputs.gitRef, 'release-')`
- [x] `.github/workflows/release.yaml:44` — branch creation: derive `release-X.Y` from version input
- [x] `.github/workflows/release.yaml:56` — `branch: release-v${{...}}` → use the derived minor-only branch name
- [x] `.github/workflows/release.yaml:67` — `target_commitish: release-v${{...}}` → use the derived minor-only branch name

### wasm-shim
- [x] `.github/workflows/release.yaml:9` — add `'release-[0-9]+.[0-9]+'` alongside existing `'release-v[0-9]+.[0-9]+'`
- [x] `.github/workflows/automated-release.yaml:45` — `release-v${{ env.WASM_SHIM_VERSION }}` → `release-${{...}}` (PR head branch)
- [x] `.github/actions/prepare-release/action.yaml:43` — `release-v$(echo...` → `release-$(echo...` (base branch construction)
- [x] `RELEASE.md` — 5 references to `release-v0.12`, `release-v0.13` etc.

### developer-portal-controller
- [x] `.github/workflows/release.yaml:8` — add `'release-[0-9]+.[0-9]+'` alongside existing `'release-v[0-9]+.[0-9]+'`
- [x] `.github/workflows/automated-release.yaml:45` — `release-v${{...}}` → `release-${{...}}` (PR head branch)
- [x] `.github/actions/create-release-branch/action.yaml:29` — `release-v$(echo...` → `release-$(echo...` (composite action)
- [x] `RELEASE.md` — 7 occurrences of `release-v`

### mcp-gateway
- [x] `.github/workflows/controller-integration-tests.yaml:6` — `release-v*` → `release-*`
- [x] `.github/workflows/tests.yaml:6` — `release-v*` → `release-*`
- [x] `RELEASING.md` — 8 occurrences of `release-X.Y.Z` → `release-X.Y`

### No workflow/doc changes needed
- **dns-operator** — already uses `release-*` globs and `release-0.2` in docs
- **authorino** — uses `release-*` glob, no branch construction
- **limitador** — no release branch references in workflows; `RELEASE.md` exists but describes an older manual process without `release-v` patterns
- **console-plugin** — `release-build.yaml` triggers on GitHub Release publish (tag-based), no branch references; `RELEASE.md` describes tag-from-commit workflow
- **policy-machinery** — uses `release-*` glob, no branch construction

## Phase 2: Rename current release branches

After all Phase 1 PRs merge, rename **only the current** release branch per repo:

| Repo | Old | New | Status |
|------|-----|-----|--------|
| kuadrant-operator | `release-v1.4` | `release-1.4` | ✅ Created (old can't be deleted — org ruleset) |
| authorino-operator | `release-v0.24.0` | `release-0.24` | ✅ Created (old can't be deleted — org ruleset) |
| limitador-operator | `release-v0.17.1` | `release-0.17` | ✅ Created (old can't be deleted — org ruleset) |
| dns-operator | `release-v0.17` | `release-0.17` | ⏳ Not done yet (for 1.5, not needed for 1.4.4) |
| console-plugin | `release-v0.3` | `release-0.3` | ✅ Created (old can't be deleted — org ruleset) |
| developer-portal-controller | `release-v0.1` | `release-0.1` | ✅ Created (old can't be deleted — org ruleset) |
| limitador | `release-v2.4` | `release-2.4` | ⏳ Not done yet (for 1.5) |
| mcp-gateway | `release-0.6.0` | `release-0.6` | ⏳ Not done yet (not in 1.4) |

No branches to rename: authorino, wasm-shim (no release branches exist yet). New `release-0.24` (authorino) and `release-2.3` (limitador) branches were created for the 1.4.4 patch release.

**Rename order** (low-risk first):
1. dns-operator, limitador (smallest changes)
2. authorino-operator, limitador-operator (granularity change)
3. console-plugin, developer-portal-controller, mcp-gateway
4. kuadrant-operator (last — most active)

### Branch protection

All repos have branch protection rulesets on existing release branches. After creating each new `release-X.Y` branch:
- [x] Verify the new branch is covered by the existing ruleset (check if the ruleset uses a glob pattern like `release-*` or individual branch names) — org-level rulesets use globs, new branches are covered
- [x] If individual branch names: add protection to the new branch before deleting the old one — N/A, org-level globs

### Pre-rename checklist
- [x] Verify no open PRs target any of the branches being renamed (retarget if any exist) — checked and retargeted for each rename

### Downstream (Konflux/RHTAP)
- [x] **rhcl-operator**: update to track `release-1.4` instead of `release-v1.4` (this repo still tracks release branches downstream; other components have moved to tracking release tags via a custom GH action)

## Phase 3: Validate with 1.4.4 patch release

Cut 1.4.4 using the renamed branches. The release prep PR for kuadrant-operator includes the `load_github_envvar.sh` fix (from Phase 1) alongside the version bump and `make prepare-release` changes. When this PR merges to `release-1.4`, the `release-operator.yaml` workflow triggers and exercises the full pipeline:

- Workflow trigger matches `release-1.4` via the new `release-[0-9]+.[0-9]+` pattern
- Workflow checks out `release-1.4` branch
- `load_github_envvar.sh` (now fixed) produces `releaseBranch=release-1.4`
- Tag creation and GitHub Release use the correct `target_commitish`
- Image build workflows trigger on the tag

> **Note on release-operator.yaml**: this workflow triggers on **any** merged PR to the release branch (not just release prep PRs). There's no tag-existence check — if a non-release PR is merged, it will attempt to create a tag from the version in `release.yaml` and fail if that tag already exists. This is existing behavior, not introduced by this migration. The fix lands naturally with the release prep.

## Phase 4: Remove old patterns (cleanup PRs to `main`)

After Phase 3 validates successfully, remove the legacy patterns from workflows:

- [ ] kuadrant-operator `release-operator.yaml` — remove `'release-v[0-9]+.[0-9]+'`
- [ ] wasm-shim `release.yaml` — remove `'release-v[0-9]+.[0-9]+'`
- [ ] developer-portal-controller `release.yaml` — remove `'release-v[0-9]+.[0-9]+'`
- [ ] Delete old release branches (requires org admin)

## Rollback

With dual patterns in place, rollback is simple — recreate the old branch name:
```bash
gh api repos/Kuadrant//git/refs \
-f ref="refs/heads/" \
-f sha="$(gh api repos/Kuadrant//git/ref/heads/release-X.Y --jq '.object.sha')"
```
Both old and new trigger patterns match, so workflows continue to work with either branch name. Tags and commit history are unaffected by branch renames.

## Verified: no impact

- **Helm chart releases** — all tag-triggered, no branch name dependency
- **Release image builds** — tag-triggered (`build-images-for-tag-release.yaml`), unaffected by branch rename
- **Branch image builds** — `build-images-branches.yaml` (kuadrant-operator, authorino-operator, limitador-operator) and `build-images.yaml` (dns-operator, wasm-shim) build dev images tagged with `github.ref_name`. After rename, the dev image tag changes (e.g., `release-1.4` instead of `release-v1.4`). These are ephemeral images with 1-week expiry, not consumed by release pipelines — cosmetic change only.
- **Dependabot/Renovate** — no configs targeting release branches
- **Prow/CI-operator/Konflux** — no configs referencing branch names
- **Makefile targets** — only `read-release-version` (version-agnostic, reads from Makefile variable)
- **Open PRs** — no open PRs currently target any release branches being renamed
- **Cross-repo branch references** — no release scripts reference other repos' branch names; `release.yaml` uses version numbers not branch names
- **Cache keys** — no workflows use branch names in cache keys
- **Downstream Konflux/RHTAP** — most components track release tags (not branches) via a custom GH action, so unaffected. **Exception**: rhcl-operator still tracks the release branch — needs a PR to update to the new branch name (tracked in Phase 2 checklist)

## References
- [RFC 0018](https://github.com/Kuadrant/architecture/blob/main/rfcs/0018-release-branch-naming.md)
- [architecture#170](https://github.com/Kuadrant/architecture/pull/170)