chore(release): document website pin and trim shipped comment

.claude/skills/release-cut/SKILL.md

@@ -73,11 +73,12 @@ the complete 27-asset set documented in `docs/architecture/release-pipeline.md`.
 It is read-only, and fails on an already-published release. Still review the
 authored text and generated commits by eye.
 
-After verification, manually publish the GitHub release. That publication
-automatically verifies its Snap assets and uploads them to `edge`.
-Installed-Snap smoke and candidate/stable promotion remain manual. Keep the
-blog draft during artifact verification; publish it in a follow-up commit and
-verify the website deployment.
+Manually publish the release; this verifies and uploads Snaps
+to `edge`. Installed-Snap smoke and candidate/stable promotion stay manual.
+After public-asset verification, publish the draft blog and update
+`apps/website/released-version.json` to the published version together.
+Follow the release pipeline's offline-download checks and verify deployment;
+never use the development/nightly version for this pin.
 
 ## Failure Safety
 

.codex/skills/release-cut/SKILL.md

@@ -73,11 +73,12 @@ the complete 27-asset set documented in `docs/architecture/release-pipeline.md`.
 It is read-only, and fails on an already-published release. Still review the
 authored text and generated commits by eye.
 
-After verification, manually publish the GitHub release. That publication
-automatically verifies its Snap assets and uploads them to `edge`.
-Installed-Snap smoke and candidate/stable promotion remain manual. Keep the
-blog draft during artifact verification; publish it in a follow-up commit and
-verify the website deployment.
+Manually publish the release; this verifies and uploads Snaps
+to `edge`. Installed-Snap smoke and candidate/stable promotion stay manual.
+After public-asset verification, publish the draft blog and update
+`apps/website/released-version.json` to the published version together.
+Follow the release pipeline's offline-download checks and verify deployment;
+never use the development/nightly version for this pin.
 
 ## Failure Safety
 

apps/web/src/index.html

@@ -26,10 +26,7 @@
         <link rel="icon" type="image/x-icon" href="assets/icons/favicon.ico" />
         <script src="assets/app-config.js" defer></script>
         <style>
-            /* Inline splash — paints immediately while the JS bundle and the
-               styles.css (~300KB) are still downloading and Angular is
-               bootstrapping. Removed from the DOM by main.ts after
-               bootstrapApplication() resolves. No assets, zero extra HTTP. */
+            /* Asset-free splash while bundles load; main.ts removes it after bootstrap. */
             #initial-splash {
                 position: fixed;
                 inset: 0;

docs/architecture/release-pipeline.md

@@ -436,8 +436,13 @@ Publishing the GitHub release is manual. That publication automatically
 verifies its Snap assets and uploads them to `edge`; installed-Snap smoke and
 candidate/stable promotion remain manual (see
 `tools/packaging/validate-snap-release-boundary.mjs`). Keep the blog post a
-draft during artifact verification, then publish it in a follow-up commit and
-verify the website deployment.
+draft during artifact verification. After the release is public and its assets
+are verified, publish the blog and advance
+`apps/website/released-version.json` to that published version in the same
+follow-up commit. Run `WEBSITE_SKIP_RELEASE_FETCH=1 pnpm nx test website --skip-nx-cache`,
+compare the generated download links with the public release assets, and
+verify the website deployment. The fallback pin must never follow the
+development/nightly version in the root `package.json`.
 
 If a Store upload fails after publication, run `publish-snap.yaml` from
 `master` with its `tag` input set to the existing public stable tag, for example