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

Replicate the dsh-facet release stack: a Gitea Actions workflow
(.gitea/workflows/release.yml) + .gitea/scripts/release.sh read the commit
subjects since the last tag, bump package.json, prepend CHANGELOG.md, tag
vX.Y.Z and publish the release via API. Agreed install ref is
#semver:^0.1.0, and tags are what 'dsh plugin --profile web update' moves
to, so the workflow is what makes updates work. Add the release.test.sh
suite (43 checks), npm scripts (test:release / release:plan /
release:notes), AGENTS.md with the commit conventions, CHANGELOG.md seed,
and the README *Releases* rules.

AGENTS.md

@@ -0,0 +1,64 @@
+# 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.
+
+What this repository ships: a dsh bundle that auto-installs a Playwright
+browser (`npx playwright install chromium --with-deps`, backgrounded when the
+browser is missing) and bridges the installed binary onto `PATH`
+(`/usr/local/bin/google-chrome-stable` + `chromium`) so dsh-ego-browser finds
+it in root/Docker containers without manual env-var or wrapper steps. See
+`index.js` for the mechanism and `README.md` for the config.
+
+## 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.
+
+## Commit as the work lands
+
+Commit each step as soon as it is finished rather than leaving it in the tree
+until the end. Two reasons, and the second is the one that bites:
+
+- An uncommitted change has no release note at all. The subject is the sentence a
+  user reads, so work that never becomes a commit never becomes a sentence.
+- A tree carrying four unrelated changes cannot be split into four honest
+  subjects after the fact — the reasoning behind each one is only in the
+  transcript by then, and the range picks its bump from whatever subjects it
+  ends up with. One `feat:` batched in with a handful of fixes is a minor bump
+  for all of them.
+
+Keep a subject to one change and the version follows from it.
+
+A commit here is local. Pushing to `master` is what releases, so it stays a
+separate, deliberate step.
+
+## 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*.