fix(release): release from master only, split jobs, ship LICENSE

[allen0099]

Summary

Closes #231, closes #232.

#231 — release.yml

• Master only. A non-dry-run dispatch on any ref other than refs/heads/master fails at the first step. The release and publish jobs check the ref again in their job-level if:. The release commit is pushed to HEAD:refs/heads/master explicitly instead of $BRANCH.
  • Dry runs may still be dispatched on any branch, since they write nothing. That is also how this PR's workflow can be rehearsed before merging.
• Split into three jobs:
  • build: runs the gate, the version bump, the tag check, the changelog promotion and uv build. It has contents: read, and checks out with persist-credentials: false, so the dev dependencies run with no write token and no PyPI token. It uploads one artifact, release-v<version>, containing the bumped pyproject.toml, uv.lock, CHANGELOG.md, release-notes.md and dist/. The same artifact is the dry-run output, replacing dry-run-v<version>.
  • release (needs: build, contents: write): installs nothing. It checks out the same github.sha, downloads the artifact, then commits, pushes, tags and creates the GitHub release. If master has moved since the dispatch, the push is rejected as non-fast-forward before anything is tagged, same as before.
  • publish (needs: [build, release], environment: pypi, the only id-token: write): downloads dist/ and runs pypa/gh-action-pypi-publish, then writes the summary.
• Workflow-level permissions are now contents: read only.
• The order of commit → tag → GitHub release → PyPI is unchanged, and the artifact that gets published is the one built from the bumped version.
• docs/DEVELOPMENT.md "Releasing" and "Rehearsing a release" describe the jobs and the master-only rule.

Not done: pinning third-party actions by digest. The issue marks it optional, and Renovate would need configuring for it.

#232 — LICENSE

• license-files = ["LICENSE"].
• Added the Typing :: Typed classifier.

For the maintainer (repo/PyPI settings, not changed here)

• pypi environment: GitHub creates it on the first run that references it. Add protection rules (required reviewer, branch restriction to master) if you want them.
• PyPI trusted publisher: if it is configured with no environment, it keeps working as is. Setting its environment to pypi ties publishing to this job.
• Rehearsal: I did not dispatch the workflow. A dry_run dispatch on this branch will exercise the build job, including the new artifact upload. The release/publish jobs only run for a real release.

Verification

• uv build into a temp dir, before and after:
  • before: no LICENSE in either artifact;
  • after: the wheel contains fastapi_cachex-0.3.7.dist-info/licenses/LICENSE, METADATA has License-File: LICENSE and Classifier: Typing :: Typed, and the sdist contains fastapi_cachex-0.3.7/LICENSE.
• actionlint (with shellcheck) on .github/workflows/release.yml only: clean.
• pre-commit run --all-files: passed.
• uv run pytest -q without live servers: 800 passed, 190 skipped.
• zensical build --strict (English docs): clean.

CHANGELOG

Under Security:

- **Releases run from master only, and only the publish step can reach
  PyPI.** `release.yml` could be dispatched on any branch, pushing the
  release commit there and publishing unmerged code, and the one job that
  installed every dev dependency also held `contents: write` and
  `id-token: write`. A non-dry-run dispatch off `master` now fails at once.
  The workflow is split into a read-only `build` job, a `release` job that
  commits, tags and creates the GitHub release, and a `publish` job in the
  `pypi` environment that alone can mint the PyPI token.
  ([#231](https://github.com/allen0099/FastAPI-CacheX/issues/231))

Under Fixed:

- **The wheel and sdist ship the LICENSE file.** `pyproject.toml` declared
  `Apache-2.0` but no `license-files`, so neither artifact contained the
  licence text the Apache-2.0 licence requires recipients to receive. The
  package also carries the `Typing :: Typed` classifier now.
  ([#232](https://github.com/allen0099/FastAPI-CacheX/issues/232))