## Why
After #23, the workflow on `robotframework` failed with `CHANGELOG.md write failed after 5 attempts (422): {"message":"repository file already exists [path: CHANGELOG.md]"}`.
Sequence from the log:
- `POST /branches` → 201 (branch created).
- `GET /branches/next-release` → 500, 500, then 200 (the readiness poll worked).
- `fetch_sha` then queried `GET /contents/CHANGELOG.md?ref=next-release` immediately after — that endpoint was still propagating and didn't return the SHA, so `fetch_sha` came back empty.
- `write_file` saw no SHA, used POST (create), and got HTTP 422 because the file genuinely existed on base (and therefore on the freshly forked `next-release`).
Different Gitea API endpoints don't share a single readiness signal for a newly created branch — `/branches` can report ready while `/contents` is still 500/404.
## Changes
- `fetch_sha` now queries `?ref=${BASE_BRANCH}` instead of `?ref=next-release`. Base is stable, and Gitea content writes are content-addressed by blob SHA, so a SHA fetched from main works for PUT on `next-release` (it was just forked from main, so the blob is identical).
- Treat 404 as "file absent, no SHA" and retry other non-200 responses up to 5× with backoff.
## Test plan
- [ ] Trigger Release.yml on `robotframework` (or another repo with an existing CHANGELOG.md on main). Confirm CHANGELOG.md and .version both write via PUT first try, and PR is created.
- [ ] First-release repo (no CHANGELOG.md on main yet): `fetch_sha` returns empty after 404, `write_file` POSTs to create — confirm this path still works.
Reviewed-on: #24
argoyle
1f9d754f61