docs: a release is a signed tag pushed with master

The README offered master builds as the `beta` branch, AGENTS.template.md
described the `latest` tag CI force-pushed, a release as a tag pushed
after master, and CI as running on every push to master, and the
repo-better-solution lens told reviewers that users get master through
`beta`.

The README now says that releases go to `stable`, the branch its install
commands pick even while the repo still holds the old `beta` branch.
AGENTS.template.md says that every pushed range adds a release entry and
goes out in one push with a signed tag on the commit master receives,
its last commit or, on the pull-request path, the merge, how to write
the entry, what every run checks before building and what a tag run also
checks, publishes and creates, what follows when one fails, what CI runs
for, and what becomes of `beta`; the lens says users get master through
releases on `stable`. The entry's rules are the owner's: at most three
sections, New, Fixes and Breaking, the most important item first and
nothing after them, and a version that is a major for a Breaking
section, a minor for New items and a patch for Fixes alone. The release
paragraph also gets the blank line that keeps it apart from the one on
local builds.

.review-gates/lenses/repo-better-solution.md

@@ -37,6 +37,6 @@ checkout (`../Crafter.*/project.cpp`) and of every user compiles against
 what `interfaces/` exports and is loaded by the binary; the CLI, the
 `CRAFTER_BUILD_*` variables, the cache an older version left under
 `~/.cache/crafter.build/` and the `bin/` layout CI globs are contracts too.
-Users get a push to master through the Flatpak's `beta` branch and a tag
-through `stable`. A change an existing `project.cpp` does not survive is a
+Users get master through releases on the Flatpak's `stable` branch. A
+change an existing `project.cpp` does not survive is a
 finding unless the range documents, in the README, what users must change.