feat: bootstrap the codeherd release process

[xico42]

This project had no release path. No LICENSE, no installable
binaries, no convention for drafting per-version notes, and no
standard for the commit messages that feed any future changelog.
Cutting 0.1.0 by hand would set no precedent and would block
downstream tooling — mise registry submission, version-pinning by
users — that depends on signed, named artefacts.

The project adopts a single self-contained commit message per
branch, drawn from six types — feat, fix, sec, revert, docs, chore
— with no Conventional Commits scopes. The squashing-commits skill
codifies the writing workflow (problem-first prose, producer-
before-consumer ordering, no housekeeping-only paragraphs) and
defers prose-level discipline to writing-clearly-and-concisely as
a required sub-skill. The creating-release skill consumes commits
in that shape: it inspects each one to decide what lands in
CHANGELOG.md, and writes docs/release-notes/.md as the
canonical per-version narrative.

The build lives in three new Make targets so the same recipe runs
locally, in CI smoke tests, and during release. A new ch version
subcommand lets an installed binary report what release it came
from — and lets the pipeline prove the version actually made it
into the artefact. The PR pipeline exercises the full cross-
compile matrix on every change, surfacing toolchain regressions
before they reach a tag.

Releases are triggered by a commit to main that touches VERSION.
The new release.yml workflow reads the file, builds the
linux/darwin × amd64/arm64 matrix via those targets, signs every
archive and checksums.txt with sigstore cosign, then creates the
v tag and the GitHub release with
docs/release-notes/.md as the body. The project ships
under Apache 2.0, and the README points users at the new mise +
manual install paths so binary consumers are not stuck building
from source.