uploads: support up to 1 GB attachments, streamed to disk (was 25 MB, buffered in memory) (batch145)

- Server streams the upload body straight to /data/uploads (a .part temp file, atomic rename on
  success), backpressure-aware, so a 1 GB file never buffers in RAM. MAX_UPLOAD_MB env (default
  1024 = 1 GB) controls the cap; error message reflects it.
- Client size guard raised 25 MB -> 1 GB.
- docker-compose documents MAX_UPLOAD_MB and the required Nginx Proxy Manager client_max_body_size.
NOTE: the actual bottleneck for the user's 9.7 MB reject is almost certainly NPM's client_max_body_size
(nginx default 1 MB) — that must be raised in the NPM admin; the app change alone can't lift it.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docker-compose.yml

@@ -17,6 +17,11 @@ services:
       # Chat uploads / recordings / transcripts on the persistent volume too, so they survive image
       # rebuilds (otherwise old shared images 404 as "broken image" after every deploy).
       - UPLOADS_DIR=/data/uploads
+      # Max chat-attachment size in MB (default 1024 = 1 GB). The app streams uploads to /data/uploads, so
+      # large files don't buffer in memory. IMPORTANT: also set Nginx Proxy Manager's client_max_body_size
+      # for remote.bizgaze.com to at least this (Advanced tab: `client_max_body_size 1024m;`) or the proxy
+      # rejects big uploads before they reach the app.
+      - MAX_UPLOAD_MB=1024
       - REC_DIR=/data/recordings
       - TRANS_DIR=/data/transcripts
     # Secrets (TURN credentials, SSO_SECRET, BIZGAZE_WEBHOOK_URL, etc.) live in