Content-hashed pkg assets (hash-files) so stale bundles can't pair with new wasm

An iPhone kept a heuristically-cached portal.js across three releases
(cached before Cache-Control: no-cache existed) and loaded it against
fresh wasm - its snippet imports 404'd, hydration never started, and
the gesture field never mounted. With hash-files = true every pkg
file is content-named and the freshly served page references exactly
its own bundle; hash.txt ships beside the binary (leptos resolves it
next to current_exe), the shell links the stylesheet through
HashedStylesheet, and instances set LEPTOS_HASH_FILES=true.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.gitea/workflows/publish.yml

@@ -68,11 +68,14 @@ jobs:
           stage=$(mktemp -d)
           cp "$CARGO_TARGET_DIR/release/portal" "$stage/portal"
           cp "$CARGO_TARGET_DIR/release/question_lint" "$stage/question_lint"
+          # hash-files = true: leptos resolves hash.txt next to the running
+          # binary, so it ships beside portal in the release dir.
+          cp "$CARGO_TARGET_DIR/release/hash.txt" "$stage/hash.txt"
           # site-root ("target/site" in Cargo.toml) is project-relative,
           # not affected by CARGO_TARGET_DIR - only the plain `cargo build`
           # outputs (release/, front/) move with that override.
           cp -r target/site "$stage/site"
-          tar -C "$stage" -czf "portal-$tag.tar.gz" portal question_lint site
+          tar -C "$stage" -czf "portal-$tag.tar.gz" portal question_lint hash.txt site
           rm -rf "$stage"
 
       # The run's own ephemeral token has write access to this repo -