ci: introduce release branch model

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\`