Dockerfile: call out multi-process limitation explicitly

The reasoning for --workers 1 was already there; adding an upfront
note that this app doesn't support multi-process/multi-replica
deployment as-is, since Login Flow v2's in-flight state is in-process
memory - not just a gunicorn flag choice, a structural constraint
until that state moves somewhere shared.

backend/Dockerfile

@@ -21,11 +21,17 @@ EXPOSE 5000
 # instance/ (sqlite db) and uploads/ (receipt photos) should be mounted as
 # volumes - see docker-compose.yml - so they survive a container rebuild.
 #
-# --workers 1: the Login Flow v2 poll state (app/auth.py _pending_flows) is
-# an in-memory dict, not shared across processes - with >1 worker,
-# /auth/login/start and the follow-up /auth/login/poll calls can land on
-# different worker processes, which never see each other's flow_id, so
-# login intermittently/always times out. Single worker (+ threads for
-# concurrency) keeps that state actually shared. Fine for this scale
-# (household tool, already SQLite-backed).
+# NOTE: this app does not support running as multiple processes. Login Flow
+# v2's in-flight state (app/auth.py _pending_flows) is a plain in-memory
+# dict, not shared across processes/machines - it only works because every
+# request within a login attempt is guaranteed to hit the same process.
+# Scaling this out (more gunicorn workers, multiple replicas, etc.) would
+# need that state moved to somewhere shared (the sqlite db, redis, ...)
+# first.
+#
+# --workers 1: with >1 worker, /auth/login/start and the follow-up
+# /auth/login/poll calls can land on different worker processes, which
+# never see each other's flow_id, so login intermittently/always times out.
+# Single worker (+ threads for concurrency) keeps that state actually
+# shared. Fine for this scale (household tool, already SQLite-backed).
 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "1", "--threads", "4", "--timeout", "60", "run:app"]