SQLBI Whiteboard 0.1.0 (dev 3211)

Add a temporary landing page for whiteboard.sqlbi.com (#11)

A deliberately small page: what the product is, a download button, and a
way to reach every
release. Something to improve on rather than something finished.

**The download cannot be a static link.** The installer file name
carries the version, and
`/releases/latest` returns 404 until a non-prerelease exists — which it
does not yet. The page
therefore resolves the download in the browser from the releases API,
picking the newest
stable release, or the newest pre-release when there is no stable one,
and labelling the
latter plainly as a preview. Without scripting, or if the API is
unreachable, every link
falls back to the releases page, which always works.

The selection logic was checked against the live API response: from
`v0.1.0-dev.3209` it picks
`SQLBI.Whiteboard.0.1.0.x64-dev.msi` at 60 MB, with the per-user
installer and portable ZIP as
secondary links, and shows the preview notice.

**`site/` is now one deployable folder.** The favicons and social card
were generated into
`assets/web`, which would have meant assembling the site from two places
at deploy time. The
generator writes them into `site/` instead, and `assets/` is gone. The
application and
installer assets regenerated byte-identically.

Colours, the icon, and the social card all come from the same brand
source as the
application, so the page and the product match without maintaining a
second palette.

SQLBI Whiteboard 0.1.0 (dev 3210)

Publish only the self-contained build (#10)

Each release carried six assets, including names like

\`SQLBI.Whiteboard.0.1.0.x64-frameworkdependent-dev-userinstaller.msi\`,
which asks a visitor
to decode four dimensions before downloading anything.

Releases now carry three: the per-machine installer, the per-user
installer, and the portable
ZIP, all self-contained. Self-contained is about 60 MB against 8 MB but
needs no .NET runtime
installed, which is the right trade for someone who just wants the
application. The
framework-dependent build is still produced and kept as a pipeline
artifact.

Documentation updated alongside: `release-management.md` records that
the chain is proven by
run 3209 and the prerelease it published, and notes the ten-to-fifteen
minute delay before
Azure DevOps queues a run so nobody concludes the trigger is broken.
Decisions 15 and 16 record
the asset choice and confirm the MIT licence, which until now had been
copied from Bravo
rather than chosen.

The pipeline could not be validated server-side this time — the
diagnostic PAT is revoked —
so this carries only a local YAML parse. The change is inside a
PowerShell script block, not
the YAML structure.

SQLBI Whiteboard 0.1.0 (dev 3209)

Do not generate a changelog for GitHub releases (#9)

Run #20260817.7 built and signed everything, collected the right assets,
and then failed in `GitHubRelease@1`:

```
Fetching the latest published release...   -> No releases are published yet
Found the initial commit: 27e1ffa...
Fetching the list of commits since the last published release...
##[error]An unexpected error occurred while fetching the list of changes.
##[error]Error: Not Found
```

With no previous release to compare against, the task attempts a
changelog spanning every
commit from the repository's initial one. That is a cosmetic feature
blocking the release it
is supposed to decorate, so it is off for both channels. The inline
notes already say what
each build is.

Everything else in that run worked: both matrix legs built and signed,
the assets were
collected per channel, and the Release stage correctly paused for
approval.