fix(nginx): forward the websocket upgrade to mempool — the UI is ws-driven

The dashboard's /app/mempool/ proxy forwarded plain HTTP only: no
Upgrade/Connection headers, so the browser's /api/v1/ws handshake reached
mempool-api as a bare GET and Express 404'd it. The mempool page loaded
fine and every REST probe was green while the user saw a UI that never
connects — the backend was fully healthy and completely unreachable in
the only way that matters to the page.

This hid behind the electrumx initial-sync outage: once sync finished and
the API answered, "mempool works" was declared from REST checks while the
websocket path stayed dead. Reported by the operator from the browser,
which is the only place it was visible.

Adds Upgrade/$http_upgrade + Connection "upgrade" to the /app/mempool/
location in both shipped sources (image-recipe snippet + scripts copy).
Live-verified on the dev node: ws through the proxy now answers 101; the
control probe without upgrade headers reproduces the 404 signature.

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

scripts/nginx-https-app-proxies.conf

@@ -112,6 +112,12 @@ location /app/photoprism/ {
 location /app/mempool/ {
     proxy_pass http://127.0.0.1:4080/;
     proxy_http_version 1.1;
+    # mempool's UI is websocket-driven (/api/v1/ws). Without forwarding the
+    # upgrade, the page loads but never connects — the backend can be fully
+    # healthy and every REST probe green while the user sees a dead UI
+    # (2026-08-09). 101 through this proxy is the only honest health signal.
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection "upgrade";
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;