[AmrasElessar]

Summary / Özet

Pushing the v2.0.0 tag from the environment I work in was rejected (HTTP 403), so the release never ran. This PR lets the Release workflow also be started by hand on main with publish ticked.

On a manual run it:

• derives the tag from VERSION in server/adminpdf/config.py;
• builds both packages and smoke-tests them;
• publishes the GitHub release, creating the tag on that commit (gh release create --target).

Tag pushes still work as before, and a pushed tag must still match VERSION. The release steps are now documented in CONTRIBUTING (TR + EN).

Type of change / Değişiklik tipi

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• 🔧 Refactor / chore
• 🔒 Security fix

Checklist

• I have read CONTRIBUTING.md
• Server checks pass (no server code changed)
• Web checks pass (no web code changed)
• I have added tests that prove my fix is effective or that my feature works (workflow change, see test plan)
• I have updated CHANGELOG.md under [Unreleased] (CI-only change)
• User-facing strings are in both Turkish and English
• The UI stays keyboard-accessible (WCAG 2.1 AA)
• Documentation is updated (CONTRIBUTING, TR + EN)

Linked issues / Bağlı issue'lar

Follow-up to #20.

Screenshots (UI changes only)

None.

Test plan / Test planı

• The workflow file parses as valid YAML.
• On this PR the Release workflow builds and smoke-tests both packages, and the publish job is skipped.
• After merge: run Release on main with publish ticked, then check that the v2.0.0 release appears with both zips attached.

---

Generated by Claude Code