ci: migrate release-please to upstream action (#3568)

## Summary

- replace `stainless-api/trigger-release-please` with the upstream
`googleapis/release-please-action`, pinned to verified v5.0.0 commit
`45996ed`
- run release-please explicitly against `main` with the repository's
manifest configuration
- use the built-in `GITHUB_TOKEN` explicitly and remove the
`STAINLESS_API_KEY` action input
- switch the config schema to upstream release-please and remove
Stainless's prerelease/beta settings
- explicitly dispatch required checks for the generated
`release-please--branches--main` PR
- keep the `publish` environment scoped to the PyPI publish job

## Impact

Release PRs and GitHub releases are now managed entirely by the
open-source release-please action. Stable release versions continue to
update `CHANGELOG.md`, `.release-please-manifest.json`,
`pyproject.toml`, and `src/openai/_version.py`; successful GitHub
release creation still gates the existing build and trusted PyPI publish
jobs.

Release Please deliberately uses `GITHUB_TOKEN`. Because GitHub
suppresses ordinary push and pull-request events created by that token,
a separate least-privilege job explicitly dispatches CI, breaking-change
detection, and CodeQL against the generated release PR. It fetches the
PR's live base SHA immediately before dispatch and restricts this path
to the exact `release-please--branches--main` ref.

## Permission audit

- release: `contents: write` for the release branch, tags, and GitHub
releases; `pull-requests: write` for release PRs; `issues: write` for PR
labels
- release PR checks: `actions: write` only to dispatch workflows and
`pull-requests: read` only to obtain the current base SHA and verify the
generated head branch
- CI and breaking-change workflows: default `contents: read`; the
secret-bearing examples job is not dispatched for release PRs
- CI build: `contents: read` only, with checkout credential persistence
disabled; the Stainless mirror's OIDC upload is isolated in a separate
Stainless-only job
- CodeQL: `contents: read` and `security-events: write` in its existing
dedicated workflow
- package build: `contents: read` only, with checkout credential
persistence disabled
- publish: `id-token: write` only for PyPI Trusted Publishing
- no App private key, Stainless credential, or PyPI credential is
exposed to the release workflow

## Validation

- release-please v17.6.0 `debug-config --dry-run`: loaded the Python
strategy with stable/default versioning and target branch `main`
- release-please v17.6.0 `release-pr --dry-run`: generated the expected
stable branch and version-file changes
- release-please config validated against the exact v17.6.0 upstream
JSON schema; current manifest baseline is `2.52.1`
- pinned action interface, outputs, branch naming, and documented
permissions verified against upstream source
- actionlint and YAML/JSON parsing
- `git diff --check`
- thermo-nuclear code-quality review: no findings

## Cutover prerequisites completed

- existing Stainless release PR #3562 was reviewed, merged, and released
successfully as
[v2.52.1](https://github.com/openai/openai-python/releases/tag/v2.52.1);
the current release workflow completed GitHub release creation, build,
and PyPI publishing in [run
30835897995](https://github.com/openai/openai-python/actions/runs/30835897995)
- GitHub rejected its built-in Actions integration as a ruleset bypass
actor, so active legacy ruleset `15951502` now excludes only
`refs/heads/release-please--branches--main`; all other
`release-please--*` branches and the two original bypass actors remain
unchanged
- the migration branch includes the published `2.52.1` manifest/version
baseline

## After merge

- remove the now-unused `STAINLESS_API_KEY` secret from the
repository/environment
- any future migration to the `openai-sdks` App should be handled
separately; this PR intentionally uses only `GITHUB_TOKEN`