add a release workflow

[ThomasWaldmann]

Releasing borgstore was fully manual so far: python -m build and twine upload on the maintainer machine, with a PyPI API token. This adds .github/workflows/release.yml, triggered by pushing a release tag, so that a release is just "update changes, merge, tag, push".

The workflow has two jobs:

• release: builds the sdist, twine checks it, checks that the sdist really is the one for the pushed tag (a missing or unfetched tag would silently give a setuptools-scm dev version), installs it with all extras into a clean venv and runs the test suite against that installation, then drafts the GitHub release with the sdist attached. It is a draft because the release notes want a human; a re-run replaces the assets instead of failing.
• pypi: uploads that same sdist to PyPI via trusted publishing, so no API token is stored anywhere. It is a separate job so that the pypi environment gate applies to the irreversible step alone.

sdist only, as before.

No test services are set up for the sdist check: the sftp, s3 and rest backend tests skip themselves without BORGSTORE_TEST_*_URL, the rclone tests skip without an rclone binary. What remains - posixfs, caching, hashing, nesting, threading - is what a sdist check needs. ci.yml keeps doing the full thing. The venv's bin goes first on PATH there, because the REST server tests spawn borgstore-server-rest from PATH.

Actions are pinned to commit SHAs.

New docs/development.rst describes the release procedure.

One-time setup needed before the first release

1. On pypi.org, add a trusted publisher to the borgstore project: owner borgbackup, repository borgstore, workflow release.yml, environment pypi.
2. Create the pypi environment in the repository settings. Nothing in it is required, but configuring required reviewers makes the upload wait for an approval - the last chance to stop a release. "Prevent self-review" has to stay off for that to be approvable by the person who tagged.

Testing

Verified locally against a clean clone at tag 0.6.1, with the Python version the workflow uses, by running the workflow's steps verbatim: build, twine check, install of the sdist with all extras into a fresh venv, 265 tests pass and 12 skip, without any test services. The version guard was checked both ways. The release-drafting shell logic was exercised with gh stubbed: the create path, the --prerelease path for a b1 tag, and the upload --clobber re-run path. Docs build clean with -n -W.

Not provable without a real tag: the artifact hand-off between the two jobs and the PyPI upload itself.