feat(release): semver beta releases with release-please; version in the footer (A99)

[CMaintz]

Semantic versioning with beta pre-releases, cut by release-please (A99). Next release: v2.0.0-beta.1.

What changes

• .github/workflows/release-please.yml: googleapis/release-please-action SHA-pinned (v5.0.0), on push to main (plus manual run), permissions: {} at the top and contents: write + pull-requests: write on the job. Uses the secret RELEASE_PLEASE_TOKEN when it exists, otherwise GITHUB_TOKEN. Dependabot already covers actions.
• release-please-config.json + .release-please-manifest.json (starts at 1.0.0, which matches the existing v1.0.0 release): one root package, simple type, root CHANGELOG.md, tags vX.Y.Z[-beta.N]. extra-files bump app/package.json and both version fields in its lock file. Versioning is prerelease / beta, and GitHub releases are marked as pre-releases. Changelog sections are feat (Features), fix (Fixes), content, perf, revert and docs. chore, ci, refactor, test, build and style are hidden and don't start a release.
• First release only: release-as: 2.0.0-beta.1 and last-release-sha (current main). The first entry lists only what lands after this PR. CHANGELOG.md is seeded with a hand-written summary of PRs chore: log v1 gaps, build as gate smoke test, refresh docs #2 to fix(explorer): responsive bar, wider legend, 3D domain names, smooth type toggles, no stranded terms #70, grouped as Content, Explorer, Search, Learning, Accounts and privacy, Security, Design, and Docs and CI.
• Site: lib/version.ts reads app/package.json at build time. It is server-only, so package.json never reaches an island. The footer shows v1.0.0 (after the Release PR merges, v2.0.0-beta.1) and the About dialog's small print shows "Atlas v…". Both link to CHANGELOG.md with EN and DA "Release notes / Udgivelsesnoter" labels. app/package.json goes from the 0.0.1 placeholder to 1.0.0.
• README "Releasing" section and decision row A99.

Verified

• mise run gate exit 0 (lint, typecheck, tests, full build, audit, gitleaks). No em or en dashes in the new text.
• A release-please release-pr --dry-run against this branch finds release v1.0.0, uses the configured last-release-sha, and would open "release 2.0.0-beta.1" with one Features entry (this PR's feat commit). It updates CHANGELOG.md, version.txt, app/package.json, app/package-lock.json and the manifest.

Owner: before or right after merging

1. Required. The repo currently has "Allow GitHub Actions to create and approve pull requests" off, so with GITHUB_TOKEN alone the workflow cannot open the Release PR. Choose one:
   • turn on Settings > Actions > General > Workflow permissions > "Allow GitHub Actions to create and approve pull requests". The gate will not run on the Release PR, which only touches CHANGELOG and version files.
   • or add a fine-grained PAT for this repo only (Contents and Pull requests: read and write) as the secret RELEASE_PLEASE_TOKEN. The gate then runs on the Release PR too.
2. After this PR merges, release-please opens "chore(main): release 2.0.0-beta.1". You merge it. release-please then tags v2.0.0-beta.1 and publishes a GitHub pre-release, and the push to main runs gate and then deploy, so the footer shows v2.0.0-beta.1. (If you set the secret after merging, re-run the workflow from the Actions tab.)
3. Then delete release-as and last-release-sha from release-please-config.json (a chore: commit). If they stay, every release proposes beta.1 again.
4. Later: every feat, fix, content or docs merge updates the open Release PR to the next beta.N. At launch, follow the README "Launch" step.