fix(release): stage build-rewritten files (sw.js, index.html) in release.sh

build.js rewrites three things during `node build.js`:
  - status/dist/*.js (bundle output)
  - status/index.html (CSP hash for inline bootstrap)
  - status/sw.js     (cache name derived from bundle content)

release.sh was only staging status/dist/. Result: when a release didn't
touch index.html or sw.js source, the post-build modifications to those
two files were left unstaged, the commit included only dist/, and the
tarball shipped the stale sw.js. Clients then kept the previous SW
cache name -> activate handler never wiped the cache -> precached old
bundles served forever even after they were "updated" on disk.

Now stage index.html and sw.js too. They're tracked (not gitignored)
so a plain `git add` is enough; the commit is a no-op when nothing
actually changed.

scripts/release.sh

@@ -61,9 +61,14 @@ fi
 # ── 3. Commit + push ──────────────────────────────────────────────────────
 echo "[3/6] Committing + pushing"
 git add dashcaddy-api/package.json
-# status/dist/ is .gitignored but its tracked files still need re-staging on rebuild.
-# -f bypasses the ignore for these specific paths.
+# Everything the build rewrites must be staged or the tarball ships stale
+# copies. status/dist/ is .gitignored (-f bypasses); index.html and sw.js are
+# tracked but get rewritten by build.js (CSP hash + SW cache tag derived from
+# bundle content). Without staging sw.js, clients keep the old cache name
+# and never see the new bundles.
 [[ -d status/dist ]] && git add -f status/dist/ 2>/dev/null || true
+[[ -f status/index.html ]] && git add status/index.html 2>/dev/null || true
+[[ -f status/sw.js ]] && git add status/sw.js 2>/dev/null || true
 git commit -m "chore(release): bump to $VERSION" >/dev/null
 git push gitea main >/dev/null
 COMMIT="$(git rev-parse --short HEAD)"

status/sw.js

@@ -1,4 +1,4 @@
-const CACHE = 'dashcaddy-shell-48970e1876';
+const CACHE = 'dashcaddy-shell-8ef9c82616';
 const PRECACHE = [
   '/',
   '/index.html',