SQLBI Whiteboard 1.2.2 (dev 3286)

Say what each release gives people, in one place (#86)

The GitHub release body for a stable version has been the single line
`SQLBI Whiteboard <version>.`, and the alternative the pipeline offered
— `addChangeLog` — is a list of commit subjects. That is the too-short
and the too-verbose you described, and neither answers the only question
a reader has: is this upgrade worth having.

`CHANGELOG.md` is now the one place release notes are written, and
`scripts/release-notes.ps1` the only thing that reads it. One `##
<version> - <date>` section per released version, one `###` heading per
thing a person would notice.

Three readers, none of which the other two can serve:

- **Release notes** on every pull request fails when
`Directory.Build.props` changes `VersionPrefix` and no section exists
for the new version.
- **Azure Pipelines** writes that section into the GitHub release body,
before the release is created — so an unwritten changelog stops the
release instead of being noticed after it is public. Only the
`releaseNotes` input of the stable release task changed; nothing in the
signing path.
- **Publish site** renders every section into `site/changelog.html` and
refuses to deploy a published release that has no section.

`changelog.html` becomes **What's new**: it no longer fetches releases
from the GitHub API and renders their markdown in the browser, so the
notes ship as HTML that reads without scripting and can be indexed. The
footer link across the site is renamed to match. Entries go back to
1.0.0, written from the merge history; earlier versions stay on GitHub,
where their notes already are.

Pre-release **Dev** builds are exempt everywhere — they come from every
merge and would bury the releases people actually choose between.

The gate is on the **version bump** rather than only on the release, so
the notes are written while the change is fresh, by the person who made
it. The release is still checked, because a release need not have come
from a bump.

Verified locally: all three script modes (`Verify`, `Markdown`, `Html`);
the pull-request gate against a real bump (1.2.1 → 1.2.2, passes), a
no-bump case (skips), and a bump to an unwritten 1.3.0 (exits 1); the
rendered page served over HTTP and checked against the site's own
stylesheet; and the `Markdown` output confirmed as UTF-8 with its arrows
intact. An unstyled render caught `1.2.22 September 2026` — version and
date collided when the only separator was a CSS gap — so the separator
is now a character in the markup.

The generated region is **not** committed, the way the release manifests
are not: `site/changelog.html` holds a placeholder between its markers
and the deployment fills it, so the page cannot drift from the
changelog.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>