ci: take the template's release, publish and gate fixes

[AlexeyShalaev]

clientwright was rendered from python-library-template before five of its fixes landed, so this takes them over by hand, in the rendered text with only the names changed. publish.yml and release-please.yml are now identical to a render of template d9d0a6f for this library.

Publish (bedrock-python/python-library-template#18). The check job now decides what gets published. The dispatch tag input is data passed through env:: it has to match the release tag pattern, exist, and point at a commit on master. A workflow_run start only counts when Release Please ran for a push. check waits for the push CI run on the released SHA and stops unless it passed, and the publish job checks out that SHA rather than the tag. id-token: write moved from the workflow to the publish job; check has contents: read and actions: read. The step that overwrote clientwright/__version__.py from the tag is gone: instead the tag's version has to equal the committed __version__, and a mismatch fails with both values. VERSION_FILE is clientwright/__version__.py, the file hatch reads the version from.

Attestations (bedrock-python/python-library-template#24). pypi-attestations sign runs before uv publish, so releases carry PEP 740 provenance. uv publish already ran without file arguments, so the attestation files get picked up; the comment explains why it has to stay that way.

Gate (bedrock-python/python-library-template#19). All checks passed now requires success from every job it needs. Before, a skipped job counted as passed. needs is unchanged (lint, test-core-only, test-unit, test-integration, test-requests-stack). MAY_SKIP is []: none of those jobs has an if:. live is the only job that runs on workflow_dispatch alone, and it stays out of needs, as before.

Release Please (bedrock-python/python-library-template#23). Release Please uses a token from the org's release App when RELEASE_PLEASE_APP_CLIENT_ID is set, so the release PR gets CI without a close and reopen (that is what #40 and #43 needed). Until the App exists it falls back to GITHUB_TOKEN and the run says so in a warning.

Answers file (bedrock-python/python-library-template#21). .copier-answers.yml at _commit: d9d0a6f, so copier update can reach this repo. I produced it with copier copy --vcs-ref d9d0a6f gh:bedrock-python/python-library-template using this library's answers and took the file as Copier wrote it, including the line wrap of the description.

Local evidence

actionlint 1.7.12 with shellcheck 0.11 on all four workflows: clean, apart from the two known false positives about client-id on create-github-app-token@v3 (actionlint's bundled metadata predates that input).

The "Resolve the release tag" step, extracted from this branch's publish.yml with its env and run with bash -eo pipefail in a throwaway repo with a bare origin. The repo has master's real clientwright/__version__.py (0.5.1), clientwright-v0.5.1 on that commit, and clientwright-v9.9.9 on the next one:

workflow_run, tagged clientwright-v0.5.1, clientwright/__version__.py says 0.5.1:
    Will publish clientwright-v0.5.1 (9b1186267c23caf7546705ef52595878bda43609)
    exit=0  outputs: tag=clientwright-v0.5.1 sha=9b1186267c23caf7546705ef52595878bda43609
workflow_dispatch -f tag=clientwright-v0.5.1:
    Will publish clientwright-v0.5.1 (9b1186267c23caf7546705ef52595878bda43609)
    exit=0  outputs: tag=clientwright-v0.5.1 sha=9b1186267c23caf7546705ef52595878bda43609
workflow_run, tagged clientwright-v9.9.9, clientwright/__version__.py says 0.5.1:
    ::error::clientwright-v9.9.9 is version 9.9.9, but clientwright/__version__.py at a61a575e46962d464fbd163260124cab8504ea97 says '0.5.1'
    exit=1  outputs:
workflow_dispatch -f tag=clientwright-v9.9.9:
    ::error::clientwright-v9.9.9 is version 9.9.9, but clientwright/__version__.py at a61a575e46962d464fbd163260124cab8504ea97 says '0.5.1'
    exit=1  outputs:

Not ported

• fix: cap ruff and mypy at the series the generated config was checked with python-library-template#20 (ruff/mypy caps) and docs: setup instructions match what a render contains python-library-template#22 (setup docs, NEW_LIBRARY_CHECKLIST.md) are about new renders and do not apply to an existing library.
• The rest of the ci.yml differences from a fresh render are clientwright's own and stay as they are: the workflow_dispatch trigger, the live job, test-core-only, test-requests-stack, lint-imports, and integration tests without the exit-code-5 allowance. docs.yml matches the render exactly.

The master-only deployment policy on the pypi environment comes from setup_repo.py, not from this file, and this repo does not have it yet (deployment_branch_policy is null). Until setup_repo.py is re-run here, a dispatch from another branch can still reach the environment, so its own copy of publish.yml would be the one deciding.