Fix Login Flow v2 timing out under Docker (single gunicorn worker)

_pending_flows in app/auth.py is an in-memory dict, not shared across
processes. With --workers 2, /auth/login/start and the follow-up
/auth/login/poll calls could land on different worker processes, which
never see each other's flow_id, so login would intermittently or always
time out. Only surfaced under gunicorn (Docker); the dev server is a
single process so it never hit this.

Pin to a single worker (+ threads for request concurrency) so the shared
in-memory state is actually shared. Fine at this scale - household tool,
already SQLite-backed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011b5fAoenyLtvS54oztB7ib

backend/Dockerfile

@@ -20,4 +20,12 @@ EXPOSE 5000
 
 # instance/ (sqlite db) and uploads/ (receipt photos) should be mounted as
 # volumes - see docker-compose.yml - so they survive a container rebuild.
-CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "2", "--timeout", "60", "run:app"]
+#
+# --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).
+CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "1", "--threads", "4", "--timeout", "60", "run:app"]