ci: add release-drafter + prepare-release for faster releases

[dazzling-no-more]

Summary

Adds two new GitHub Actions workflows and a release-drafter config to make releases lower-friction:

• release-drafter accumulates merged-PR titles into a draft GitHub release (tagged next) as PRs land on main. The English half of the next changelog is built up incrementally — no more starting from a blank docs/changelog/v<ver>.md on tag day.
• prepare-release is a manual workflow_dispatch that bumps Cargo.toml, Cargo.lock, android/app/build.gradle.kts (versionName + versionCode+1), pulls the drafter's accumulated body into a stub docs/changelog/v<ver>.md, and opens a PR. After merging, you push the v<ver> tag and the existing release.yml takes over.

The existing release flow (matrix build → GH release → Telegram) is untouched.

How to use

gh workflow run prepare-release.yml -f version=1.6.6

This opens a release/v1.6.6 PR with all version files bumped and docs/changelog/v1.6.6.md prefilled with English bullets like:

• added bulk parser for ids on android ([#257](url)): <expand>. Thanks @dazzling-no-more

The maintainer's job per bullet:

1. Fix verb tense (added → Add)
2. Replace <expand> with the explanatory clause matching the project's existing • headline (#NN): full explanation style

The Persian section starts as a visible [FA] translate ... placeholder above the --- separator. Push the bilingual changelog to the branch, merge the PR, then git tag v<ver> && git push origin v<ver> to ship.

Why this design

• Conventional-Commit prefixes auto-stripped. PR titles in this repo use feat:/fix:/etc.; the existing changelog convention strips them. A sed pass in prepare-release handles feat:, fix(scope):, fix(scope)!:, etc., so the maintainer doesn't.
• Visible placeholders, not HTML comments. A forgotten <!-- TODO --> would silently leak into the GitHub Release page and the Telegram post. [FA] and <expand> markers ship visibly if missed — much louder failure mode.
• Tag pushing stays manual. This repo has tag protection and a workflow_dispatch re-trigger escape hatch in release.yml specifically because broken-build-on-immutable-tag is hard to recover from. Auto-tag-on-merge would make that scenario more likely; the explicit git tag && git push is the "ship it" gesture.
• No self-hosted runner contention. Both new workflows run on ubuntu-latest. The Hetzner build runners are reserved for the existing release matrix.

Files

• new: .github/release-drafter.yml — drafter config (flat bullet template, autolabeler keyed on Conventional-Commit prefixes)
• new: .github/workflows/release-drafter.yml — runs on push-to-main and PR events; bootstraps the autolabeler labels (release-prep, type: feature, etc.) idempotently on every run
• new: .github/workflows/prepare-release.yml — the version-bump + PR-open workflow described above
• modified: .github/workflows/release.yml — the leading-comment stripper for the release body now uses inline Python with the same regex as the Telegram script, so both surfaces agree on what counts as "the leading comment block"
• modified: .github/scripts/telegram_release_notify.py — extracted _strip_leading_comments() with doctests covering single comment, consecutive comments, multi-line comment, blank-separated comments, no comments, and mid-file comments preserved

Test plan

• Merge this PR; verify release-drafter creates a next draft on the next push to main
• Open a normal feature PR; verify the autolabeler applies a type: * label and the draft picks up the bullet
• Run gh workflow run prepare-release.yml -f version=<next-version>; verify the PR opens with all version files bumped and the changelog stub matches expectations
• Confirm python3 -m doctest .github/scripts/telegram_release_notify.py passes (covers the regex change)
• Confirm a real release through the new flow produces a clean GitHub Release page (no [FA]/<expand> markers, no <!-- --> leaks) and a clean Telegram post

Rollout note

When this lands, GitHub may need "Allow GitHub Actions to create and approve pull requests" enabled in repo Settings → Actions → General for the prepare-release workflow's gh pr create to work. If gh pr create errors with 403 on the first run, that's the fix.