fix(deploy): build/serve the new web/ Vite app instead of the old webpack build

The deploy pipeline (.gitea/workflows/deploy.yml -> Dockerfile) never got
updated when the frontend was rewritten under web/ -- it was still doing
`npm ci`/`npm run build` at the repo root and copying the old app's umd/,
css/, index.html, etc. into the nginx image. Every deploy therefore kept
shipping the old app regardless of what was actually on dev, no matter how
much of the rewrite had landed.

Dockerfile now builds from web/ (Vite) and copies its self-contained
dist/ output (index.html + content-hashed assets/, no separate umd/css/
img/audio/manifest/service-worker/firebase files -- none of that exists
in the new app). VITE_TINODE_API_KEY is what src/lib/config.ts actually
reads (Vite only exposes VITE_-prefixed env vars to client code), so the
existing TINODE_API_KEY build-arg is now renamed into that on its way
into the build environment instead of passed through under its old name.

nginx.conf updated to match: index.html stays no-cache (its URL never
changes, so a stale cached copy would keep pointing at deleted asset
filenames after a deploy), assets/ gets a long immutable cache (Vite
content-hashes every filename there, so a new build never reuses an old
URL). Dropped the old umd/ and img/ location blocks, neither exists in
the new build.

Verified locally: `docker build` succeeds, the container serves the new
app's real index.html/assets with the intended cache headers, and an
unknown client-side route (/messages/slf) correctly falls back to
index.html.

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

docker/nginx.conf

@@ -5,21 +5,20 @@ server {
     root /usr/share/nginx/html;
     index index.html;
 
-    # Tinode webapp uses real (History API) client-side routing, so any unknown path
-    # can safely fall back to index.html -- the app resolves the actual view/topic
-    # client-side from the path itself once index.html loads.
+    # The webapp uses real (History API) client-side routing, so any unknown path can safely fall
+    # back to index.html -- the app resolves the actual view/topic client-side from the path itself
+    # once index.html loads. index.html itself is never content-hashed, so it must always be
+    # revalidated -- otherwise a browser holding a cached copy would keep requesting the *previous*
+    # deploy's now-deleted /assets/*.js filenames after a new deploy replaces them.
     location / {
+        add_header Cache-Control "no-cache";
         try_files $uri $uri/ /index.html;
     }
 
-    # Filenames here aren't content-hashed, so a long/immutable cache would keep
-    # serving a stale bundle after every deploy. Force revalidation instead:
-    # cheap 304s when unchanged, immediate pickup of new content when not.
-    location /umd/ {
-        add_header Cache-Control "no-cache";
-    }
-
-    location /img/ {
-        add_header Cache-Control "public, max-age=86400";
+    # Vite content-hashes every filename under assets/ (e.g. index-DYjopaLI.js) -- a new build never
+    # reuses an old asset's URL, so these can be cached aggressively and indefinitely; a stale cached
+    # copy simply never gets requested again once index.html points at the new hashed filenames.
+    location /assets/ {
+        add_header Cache-Control "public, max-age=31536000, immutable";
     }
 }