docs(changelog): make the first release v0.1.0, and fold in the alpha section

[barbatos2011]

Was stacked on #222. That merged as 235ff82, so this branch is rebased onto develop and now carries only its own two commits — CHANGELOG.md, one step in release.yml, and one line in specs/.

The problem

The changelog described a 0.1.0-alpha release that never happened. There are no tags in this repository and no published releases:

$ git tag                                          # (empty)
$ gh release list -R tronprotocol/tron-deployment  # (empty)

So that heading documented a version nobody could install, and both link references at the bottom — compare/v0.1.0-alpha...HEAD and releases/tag/v0.1.0-alpha — were dead. It also appeared twice in a row until #222 fixed that.

The change

Everything is one release. [Unreleased] and [0.1.0-alpha] merge into a single ## [0.1.0], and the ### Added list is split into Foundation (what the alpha section described — the CLI, the intent schema, render, SSH) and Since (everything after). Changed / Fixed / Security / Repository changes carry over unchanged. A fresh empty ## [Unreleased] sits on top, per Keep a Changelog.

Content is preserved line for line apart from the two intro paragraphs, which become one. Verified rather than eyeballed — comparing every non-heading, non-blank, non-linkref line before and after:

old content lines: 358   new: 368
LOST from old (2):
  - The agent-ergonomics arc lands across four sequenced PRs:
  - Initial public alpha. The project transitions from a curated set of HOCON
ADDED in new (12):   # the rewritten intro, plus **Foundation** / **Since**

Why 0.1.0 and not 0.1.0-alpha

goreleaser runs with prerelease: auto, so a tag carrying a pre-release suffix is filed as a pre-release — and /releases/latest, which scripts/install.sh queries and the README one-liner depends on, does not return pre-releases. The suffix would cost a working install path in order to restate something 0.x already says under semver.

Why 0.1.0 and not 1.0.0

The public surface here is not only the CLI flags. It is schemas/intent.schema.json (~50 fields), the ~30 machine-readable schemas under schemas/output/, and the exit-code contract that AGENTS.md tells agents to branch on. The constitution requires strict semver, so 1.0.0 would freeze all of that behind a major-bump promise before any of it has met a real user. TODOS.md also still carries four deferred decisions, one an unreconciled overlap between scripts/db_cp.sh and trond snapshot clone.

0.2.0, 0.3.0 and so on from here; 1.0.0 when those schemas have been through real use and the project is willing to back them.

The date placeholder, and a guard for it

The date stays 2026-XX-XX because releases are cut by hand (#222) and the date is not known until someone dispatches the workflow. That is an easy thing to ship unfilled and invisible afterwards, so release.yml now checks — before it builds anything — that the top released section names the tag being released and ends in a real date.

Both failure modes were exercised locally:

REJECT (placeholder date):  v0.1.0 / '## [0.1.0] — 2026-XX-XX'   ← the file's current state
ACCEPT:                     v0.1.0 / '## [0.1.0] — 2026-09-01'
REJECT (version mismatch):  v0.2.0 / '## [0.1.0] — 2026-09-01'

Dispatch on the tag so GITHUB_REF_NAME is the tag: gh workflow run release.yml --ref v0.1.0.

Also

specs/001-trond-cli-platform/tasks.md T091 is an open, unchecked task telling whoever runs it to tag v0.1.0-alpha. Repointed at v0.1.0. The phased plan below it (v0.1.0-alpha → v0.2.0-alpha → v0.3.0-alpha, one per user story) is deliberately left as written — it records what was planned, and it was not followed; everything landed on develop untagged.

Not in this PR

Filling in the release date. That happens when someone decides to tag, and the guard above will refuse the release until they do.