ci: publish a release on every push to master

Tags are what make `dsh plugin update` work at all: a plugin installed as a
bare `git+https://…/repo.git` is pinned to a commit in the profile's lockfile,
so with no tags there is nothing for an update to move to. This adds the
pipeline that creates them.

`.gitea/workflows/release.yml` runs on a push to master and on manual dispatch:
it reads the commit subjects since the last tag, derives the bump, prepends a
`CHANGELOG.md` section, commits and tags `vX.Y.Z`, and publishes the Gitea
release with those subjects as the body. The range with no tags yet is the
whole history, so the first release describes everything it contains.

The logic lives in `.gitea/scripts/release.sh` rather than in the YAML so it can
run — and be checked — without a runner: `npm run test:release` exercises it
(43 checks), `npm run release:plan` says whether HEAD would release, and
`npm run release:notes` prints the notes it would publish. `AGENTS.md` states
the subject conventions a contributor has to follow, because the subject is both
the version decision and the sentence a user reads in the release notes.

One property worth knowing: with no tags yet the version released is the one
`package.json` already declares — no bump is applied to a version that has never
been published — so the first tag is `v0.1.0`, and the bump rules take effect
from the second release onward.

AGENTS.md

@@ -0,0 +1,39 @@
+# Working in this repository
+
+`master` releases itself. Every push runs `.gitea/workflows/release.yml`, which
+reads the commit subjects since the last tag, bumps `package.json`, prepends
+`CHANGELOG.md`, tags `vX.Y.Z`, and publishes the Gitea release with those
+subjects as the body.
+
+## Commit subjects are release input
+
+The subject is both the version decision and the sentence a user reads in the
+release notes. Write it for that reader:
+
+- `feat: …` — the change adds a capability. Minor bump: `0.1.0` → `0.2.0`.
+- `feat!: …` or `fix(x)!: …` — the change breaks an existing install. Major
+  bump: `0.1.0` → `1.0.0`, and the note lands under **Breaking**. `[major]`
+  anywhere in the subject does the same when a `!` will not fit.
+- `fix: …`, `docs: …`, or a plain sentence — everything else. Patch bump:
+  `0.1.0` → `0.1.1`.
+- `[skip release]` — this push publishes nothing.
+
+`feat` has to be a word, so `Fix the feature flag leak` is a patch. Only the
+subject line is read; the body is not.
+
+## The release job owns the version and the changelog
+
+`package.json`'s `version` and `CHANGELOG.md` are the job's to write, derived
+from the commits. Pushing to `master` is the whole trigger — the tag and the
+release come with it.
+
+## Checking before pushing
+
+```sh
+npm run release:plan     # would this HEAD release? (yes/no)
+npm run release:notes    # the exact notes it would publish
+npm run test:release     # the checks behind the bump and the notes
+```
+
+The rules in full — the marker table, first-release behaviour, how prose commits
+are handled — are in the README under *Releases*.