Create GitHub releases automatically on version tags

[kindermax]

What changed

Added a github-release job to the existing tag-triggered release workflow. On every v* tag push (i.e. each lets release), alongside the PyPI publish, it now creates a GitHub Release using the built-in gh CLI:

• Notes from the changelog: extracts the ## [<version>] section from CHANGELOG.md; falls back to GitHub's auto-generated notes (from merged PRs) when the section is missing
• Pre-release marking: versions that aren't plain X.Y.Z (e.g. 1.26.0rc1) are flagged as pre-releases
• Idempotent: skips if the release already exists, so workflow re-runs (e.g. after a PyPI failure) don't fail
• Runs independently of the deploy job and uses the workflow's own github.token with contents: write scoped to the job — no new secrets required

Also documented the behavior in docs/development.rst and CHANGELOG.md.

Why

GitHub Releases were created manually up to v1.1.3 (2024) and abandoned since; all newer versions exist only as bare tags. This automates them so each release gets a browsable page with its changelog section.

Notes for reviewers

• No third-party actions used — the logic is ~20 lines of shell, avoiding a supply-chain dependency in a workflow with write permissions
• Changelog extraction and argument composition were tested locally against the real CHANGELOG.md for three representative tags: v1.25.0 (final, has changelog section → notes from file), v1.26.0rc4 (rc, no section → pre-release with generated notes), v1.15 (old final, no section → generated notes)
• Tags between v1.2 and v1.26.0rc4 are not backfilled; this only affects future tags