chore: drop Codeberg release workflow and document GitHub-only CI

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/DEVELOPMENT.md

@@ -35,7 +35,7 @@ executable per platform.
 | Persistence | Plain JSON files (`gosentry.json`, `jobs.json`) |
 | Build | `go build` driven by the scripts in `scripts/` |
 | Reproducible builds | Docker (`golang:1.22-bookworm` based [Dockerfile](../Dockerfile)) |
-| CI | GitHub Actions and Forgejo Actions (Codeberg) |
+| CI | GitHub Actions (release builds on tagged GitHub Releases) |
 
 CGO is mandatory. The Fyne desktop backend links against native OpenGL and
 window-system libraries, so a C compiler must be present for every build,
@@ -255,12 +255,11 @@ The version stamped into the file names and into the binary comes from
 
 ## 6. CI
 
-Tagged releases are built automatically on both GitHub and Codeberg:
+Tagged releases are built automatically on GitHub when a release is published:
 
 - `.github/workflows/release.yml` — GitHub Actions.
-- `.forgejo/workflows/release.yml` — Forgejo Actions (Codeberg).
 
-Both run inside `golang:1.22-bookworm` (the same base image as the
+The job runs inside `golang:1.22-bookworm` (the same base image as the
 [Dockerfile](../Dockerfile)), install the cross toolchain, and call
 `scripts/ci-build-release.sh`, which builds and packages all three artifacts:
 
@@ -290,15 +289,16 @@ Before tagging:
 4. Run `scripts/test.bat` (or `go vet ./... && go test -race ./...`) and push
    `main`, so the tag lands on a commit the forge actually has.
 
-Then create and publish a release with a matching `v` tag on the forge (GitHub
-Releases / Codeberg releases). `origin` is the Gitea repository, and GitHub is a
-push mirror of it, so the tag is pushed to Gitea and reaches GitHub through the
-mirror — never created on GitHub directly (see
+Then create and publish a release with a matching `v` tag on GitHub. `origin` is
+the Gitea repository (`gitea.mixdep.ru/mix/gosentry`), and GitHub
+[`mixeme/gosentry`](https://github.com/mixeme/gosentry) is a pruning push mirror
+of it, so the tag is pushed to Gitea and reaches GitHub through the mirror —
+never created on GitHub directly (see
 [Releasing through the GitHub push mirror](#releasing-through-the-github-push-mirror)):
 
 ```bash
 git tag v0.11.5
-git push origin v0.11.5   # Gitea; and to the Codeberg remote
+git push origin v0.11.5   # Gitea
 
 # wait for the mirror, then confirm GitHub actually has the tag
 git ls-remote --tags https://github.com/mixeme/gosentry.git v0.11.5
@@ -310,14 +310,8 @@ Publishing the release triggers the workflow: it strips the leading `v` from
 the tag and injects it as the version (so the tag must match `version.go`),
 builds the archives, and attaches them to that release. `workflow_dispatch`
 also allows a manual, upload-free build to smoke-test the pipeline.
-
-Codeberg publishing needs a repository secret named `RELEASE_TOKEN` (a Codeberg
-access token with the `write:repository` scope) under
-**Settings → Actions → Secrets**. Without it the build and packaging steps still
-succeed, but the upload step fails on authentication and takes the job down with
-it, leaving a published release with no attached assets. GitHub needs no such
-setup: `softprops/action-gh-release` falls back to the built-in `GITHUB_TOKEN`,
-and the workflow already grants it `contents: write`.
+`softprops/action-gh-release` uses the built-in `GITHUB_TOKEN`; the workflow
+already grants it `contents: write`.
 
 ### Releasing through the GitHub push mirror
 
@@ -348,5 +342,4 @@ them, so once the release sits on a mirrored tag, later synchronisations leave
 it alone. Two consequences follow. Moving a published tag in Gitea force-pushes
 it on GitHub and leaves the release pointing at a different commit, and deleting
 a published tag in Gitea destroys the GitHub release along with its uploaded
-archives — neither is recoverable from the mirror side. Codeberg is unaffected:
-its releases live in the same forge as its tags.
+archives — neither is recoverable from the mirror side.