feat: tag and publish a Gitea release on every push to master

A plugin installed as a bare git+https URL is pinned to a commit, so with no
tags there is nothing for `dsh plugin update` to move to. The workflow 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. The decision logic lives in .gitea/scripts/release.sh so it runs
and is tested without a runner (`npm run test:release`).

README.md

@@ -171,6 +171,42 @@ compose a session:
 dsh --profile web --dump-config | grep -A 3 preset-facet
 ```
 
+## Releases
+
+`.gitea/workflows/release.yml` runs on every push to `master`: it works out the
+range since the last tag, bumps `package.json`, prepends a `CHANGELOG.md`
+section, commits and tags `vX.Y.Z`, then creates the Gitea release with the
+commit subjects as the body.
+
+The bug it fixes is not tidiness. Installed as a bare `git+https://…/repo.git`,
+a plugin is pinned to a **commit** in the profile's lockfile, so with no tags
+there is nothing for `dsh plugin update` to move to. Point the profile at
+`#semver:^0.1.0` and the updates follow releases instead:
+
+```jsonc
+"dsh-facet": "git+https://git.notexpectedyet.com/Not-Expected-Yet/dsh-facet.git#semver:^0.1.0"
+```
+
+The bump is read from the commit subjects being released:
+
+| in a commit subject | effect |
+|---|---|
+| `feat`, as its own word (`feat:`, `feat(x):`) | minor — `0.1.0` → `0.2.0` |
+| `feat!:` / `fix(x)!:` / `BREAKING` | major — `0.1.0` → `1.0.0` |
+| `fix:`, `docs:`, prose, anything else | patch — `0.1.0` → `0.1.1` |
+| `[minor]` / `[major]` | force the bump when the subject cannot carry it |
+| `[skip release]` | this push publishes nothing |
+
+Only the **subject** line is read, and `feat` has to be a word — `Fix the feature
+flag leak` is a patch, not a minor. With no tags yet, the version already in
+`package.json` is what gets tagged, so the first release matches the code.
+
+The logic lives in `.gitea/scripts/release.sh` so it runs without a runner:
+`npm run test:release` exercises it — an empty range, a repository with no tags
+yet, a `feat` that is only a word — `npm run release:plan` says whether the
+current HEAD would release, and `npm run release:notes` prints the notes it
+would publish.
+
 ## Development
 
 ```sh