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

[AlexeyShalaev]

mattermind was rendered from python-library-template before the template's recent release and CI fixes, so it still has the old publish, gate and release workflows. This brings them over by hand, taking the text of a render of the template at d9d0a6f and changing only the names.

Publish (bedrock-python/python-library-template#18, bedrock-python/python-library-template#24). The check job now decides what reaches PyPI. The dispatch tag input is only data: it reaches the shell through env:, has to match the release tag pattern, exist, and point at a commit on master. The publish job checks out the SHA that check resolved, not the tag. check waits for the CI push run on that SHA and refuses anything that did not pass. The "Set version from release tag" step is gone: the tag's version has to match the committed one, and a mismatch now stops the release with both values instead of being overwritten. id-token: write moved from the workflow to the publish job. Before uv publish, pypi-attestations sign creates PEP 740 attestations. uv publish was already called without file arguments, so it picks up the .attestation files.

One addition beyond the template: mattermind keeps a static version in pyproject.toml, and that is what hatch builds with. In the template the version comes from __version__.py through [tool.hatch.version]. Release Please bumps both files here, but checking only __version__.py would leave the version that actually ships unchecked. The worst case is a tag on a commit whose pyproject.toml still has the previous version: --check-url would skip that upload and the run would end green with nothing published. So the step compares the tag with pyproject.toml too. That is five lines after the template's own check, plus the comment above the step. Making the version dynamic, as the template does, would also remove the duplication, but that is a packaging change and out of scope here.

Gate (bedrock-python/python-library-template#19). All checks passed used to fail only on failure or cancelled, so a skipped job counted as passed. Now every job in needs has to end success. needs is still [lint, test]. MAY_SKIP is []: neither job has an if:, so neither is skipped by design on any event.

Release Please (bedrock-python/python-library-template#23). It uses a token from the org's release App when RELEASE_PLEASE_APP_CLIENT_ID is set, so CI starts on the release PR without a close and reopen. Until the App exists it falls back to GITHUB_TOKEN and the run shows a warning. The config and manifest inputs are unchanged.

Answers file (bedrock-python/python-library-template#21). .copier-answers.yml, written by hand in the rendered format at _commit: d9d0a6f, so copier update has something to start from.

Two small template fixes to docs.yml came along: the pages concurrency group, so two quick pushes don't race onto Pages, and --locked on the docs sync (uv lock --check is clean on master).

Local evidence

actionlint (actionlint-py, with shellcheck) is clean on all four workflows, apart from the two known findings about client-id on create-github-app-token@v3. Those come from actionlint's outdated bundled metadata for that action.

The "Resolve the release tag" step, taken from this branch's publish.yml and run with bash -eo pipefail in a throwaway repo with a bare origin, using mattermind's real pyproject.toml and __version__.py:

dispatch, matching tag:
Will publish mattermind-v0.2.2 (b69a9b190432b693f2bdd90188d8400e78b8cb0b)    exit=0
dispatch, tag disagrees with __version__.py:
::error::mattermind-v0.2.3 is version 0.2.3, but src/mattermind/__version__.py at b69a9b190432b693f2bdd90188d8400e78b8cb0b says '0.2.2'    exit=1
dispatch, __version__.py agrees, pyproject.toml does not:
::error::mattermind-v0.2.4 is version 0.2.4, but pyproject.toml at bf5d34f30af880c632d4ecb15ced1aea47277286 says '0.2.5'    exit=1
workflow_run, matching tag on the pushed SHA:
Will publish mattermind-v0.2.2 (b69a9b190432b693f2bdd90188d8400e78b8cb0b)    exit=0

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 for new renders and don't apply to an existing library.
• --no-dev --group docs on the docs uv run steps: the template's dev and docs dependencies are groups. Here they are extras, and uv run does not install the dev extra, so there is nothing to fix.
• The template's test-integration job and Codecov upload: mattermind's integration tests need a real Mattermost and LLM, so leaving them out of CI is deliberate, and the Codecov upload is a feature rather than a fix.
• The rest of ci.yml differs because of the library's own layout (src/, extras, Python 3.12 to 3.14, an 80% coverage floor), not because a fix is missing.