docs: add a contributing guide

Codeberg became canonical for issues, PRs and releases, but there was
nothing telling a contributor how any of it works — no CONTRIBUTING.md at
all, and no contributor entry point in the README.

The workflow it documents is issue-first: a feature needs a yes-or-no
before it needs code, since whether Calendula should do a thing is the one
decision a patch cannot make. Both features and bugs get a milestone, and
that milestone names the branch a PR targets (2.18.0 -> release/v2.18.0),
because main is a release trigger rather than a staging area. Typo and docs
fixes skip straight to a PR — an issue-per-typo helps nobody.

Two traps get their own sections because both waste a contributor's whole
afternoon: translations never go through PRs (Weblate owns every values-*
file, German included, and overwrites hand-edits on the next sync), and a
clone without --recurse-submodules cannot configure at all, since
floret-kit is a composite build compiled from source.

The rules section is the invariants that actually turn into review
comments — no network, no second database, no hand-patching UI state after
a write, domain/ free of Android imports, JVM-first tests, and the
reproducible-build flags that the official F-Droid repo depends on.

.forgejo/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,41 @@
+<!--
+Thanks for contributing to Calendula!
+
+Please skim CONTRIBUTING.md if you haven't:
+https://codeberg.org/jlmakiola/calendula/src/branch/main/CONTRIBUTING.md
+
+Two things it's easy to get wrong:
+  • Features need a discussed issue first — an undiscussed feature PR may be
+    closed unmerged even when the code is good.
+  • Target the release branch for your issue's milestone (milestone 2.18.0 →
+    release/v2.18.0), not main. If you targeted main, just say so below and it
+    will be retargeted.
+-->
+
+### What this changes
+
+
+### Why
+
+<!-- Closes #123 — link the issue this implements or fixes. -->
+
+
+### How it was tested
+
+<!--
+Which of these ran green, and anything you exercised by hand. On-device notes
+are especially useful for UI changes.
+
+  ./gradlew lint test assembleDebug
+  python3 scripts/check_translations.py
+-->
+
+
+### Checklist
+
+- [ ] There's an issue for this, and (for a feature) it got a go-ahead
+- [ ] Targeting the release branch for that issue's milestone — or `main`, noted above
+- [ ] `./gradlew lint test assembleDebug` passes locally
+- [ ] No `values-*/strings.xml` touched (Weblate owns those; new English strings in `values/` are fine)
+- [ ] `CHANGELOG.md` updated under `## [Unreleased]`, if the change is user-visible
+- [ ] No planning or design documents committed