A weekly schedule releases the pending release-please PR automatically

## User story

As a **maintainer**, I want **the open release-please release PR merged on a weekly schedule** so that **accumulated `feat`/`fix` commits ship as a versioned PyPI release every week without me remembering to click merge, while the actual upload still passes a human gate**.

## Why

Once release-please (#415) lands, cutting a release becomes "merge the always-open release PR", and merging drives the tag/GitHub Release that OIDC Trusted Publishing (#412) consumes. That still leaves a human deciding *when* to merge. A weekly scheduled job merges the pending release PR on a fixed cadence, so semver2 bumps derived from Conventional Commits turn into releases predictably. The PyPI upload itself remains gated by the `pypi` environment reviewer from #412 — the schedule automates *cadence*, not the final publish approval (semi-automatic by decision).

## Acceptance criteria

- [ ] A scheduled workflow (`schedule:` cron, weekly) plus `workflow_dispatch` for manual runs.
- [ ] When an open release-please release PR exists and its checks are green, the job merges it; when none exists, the job no-ops (weeks with no releasable commits produce no release).
- [ ] Merging drives the *existing* release-please tag/Release creation and the existing `publish.yml` path — no second publish route is introduced.
- [ ] The PyPI upload stays gated by the `pypi` GitHub Environment reviewer from #412; the weekly job prepares the release, a human approves the upload.
- [ ] Least-privilege `permissions:` on the job, scoped to what merging the release PR requires.
- [ ] CONTRIBUTING documents the weekly cadence and the retained manual approval gate in one paragraph.

## Out of scope

- release-please configuration itself (#415).
- The OIDC Trusted Publishing mechanism and environment reviewer setup (#412).
- Fully unattended publishing — the human approval gate is deliberately retained.

## Notes

- **Blocked by #415** (needs the always-open release PR to merge) and **#412** (the trusted publish path and environment gate this cadence feeds). Transitively depends on #400 (branch rename to `main`) and #416 (Conventional Commits enforcement) via #415.
- Implementation gotcha to verify: a PR merged with the default `GITHUB_TOKEN` does not trigger downstream workflows, so the release-please run that creates the tag/Release may not fire. Merging via an app token / PAT, or release-please's own release step, likely needed to keep the tag → `publish.yml` chain intact.
- Meta/chore — no milestone, matching #415 and #412.

Start by reviewing the release-please setup from #415, the existing publish.yml path and environment gate from #412, then trace how the release PR is identified and how its merge creates the tag and Release. Verify the downstream workflow trigger behavior, add the weekly/manual entry points, and update CONTRIBUTING; done means green release PRs merge, absent PRs no-op, and publishing still pauses for pypi approval.

Escrita pelo modelo de indexação a partir do texto da issue.