ci: introduce release branch model

[andreahlert]

Part of #715

Problem

Currently all release work happens on `main`. During the RC voting period (72+ hours), any commit merged to `main` is not included in the release, and there is no safe place to cherry-pick critical fixes without risking the RC.

Solution

Adopt a two-branch model per release series (similar to Airflow):

• `vX.Y-test`: working branch where cherry-picks land while an RC is being voted on
• `vX.Y-stable`: clean branch, only updated when an RC is cut. Tags are created from here.

Workflow

1. When preparing a release, create `vX.Y-test` and `vX.Y-stable` from `main`
2. Cherry-picks go to `vX.Y-test`
3. When cutting an RC, fast-forward merge `vX.Y-test` into `vX.Y-stable`, tag from there
4. If the RC fails vote, fix on `vX.Y-test`, cut new RC
5. After release, delete `vX.Y-test` (keep `vX.Y-stable` for future patches)

Acceptance criteria

• Document the branch model in `scripts/README.md`
• Add a script/command to create the branch pair
• Update `apache_release.py` to work with release branches instead of `main`

[andreahlert]

@skrawcz @elijahbenizzy this one needs alignment before anything else. the two-branch model (test + stable) adds complexity but gives us a safe place to cherry-pick during vote periods. question is whether we actually need it at this stage or if it's overkill for our release cadence. how often do you end up needing to cherry-pick fixes while an RC vote is open?

[elijahbenizzy]

I like this idea -- I would like to first get a succesful one out and then let's revisit this?