Fix: Enforce single-worker deployment for session cache cluster safety

Addresses: Backend session cache not cluster-safe (multi-worker issue)

Problem:
- Session cache is process-local (InMemorySessionCache)
- Multi-worker deployments (uvicorn --workers N) create separate processes
- Each process has its own independent session cache
- Sessions cached in Worker A are invisible to Workers B, C, D
- Users randomly logged out when requests land on different workers
- Also affects RuntimeState, rate limiter, and background jobs

Solution (Option A - Strict single-worker enforcement):
- Enhance startup validation with clearer error messages
- Update error messages to explain the problem and how to fix it
- Document single-worker requirement prominently in Docker configs
- Update module docstrings to clarify constraints

Changes:
1. app/startup.py:
   - Enhanced _check_single_worker_mode() error message with troubleshooting
   - Enhanced _stage_check_worker_mode_and_acquire_lock() error message
   - Removed unused import

2. app/utils/session_cache.py:
   - Updated module docstring to explain constraints more clearly
   - Added references to deployment documentation
   - Clarified multi-worker solution for future implementation

3. app/utils/runtime_state.py:
   - Updated module docstring with deployment constraint references
   - Aligned messaging with session_cache.py

4. Docker/Dockerfile.backend:
   - Added comprehensive comments about single-worker requirement
   - Explained impact in multi-worker deployments
   - Referenced deployment constraints documentation

5. Docker/docker-compose.yml, compose.prod.yml, compose.debug.yml:
   - Added documentation comments about BANGUI_WORKERS constraint
   - Explained why single-worker is required

6. backend/tests/test_startup_integration.py:
   - Fixed test unpacking to match function return signature (3 values, not 2)

This ensures multi-worker deployments fail loudly at startup with clear
guidance on what went wrong and how to fix it. The database-backed scheduler
lock provides defense-in-depth for container orchestration scenarios.

For future multi-worker support, implement:
- Redis or database-backed session cache
- Shared RuntimeState coordination
- Distributed APScheduler backend

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

backend/app/utils/runtime_state.py

@@ -24,18 +24,26 @@ IMPACT IN MULTI-WORKER DEPLOYMENTS:
   - fail2ban activation/recovery tracking (pending_recovery, last_activation)
     is per-worker and unreliable across processes.
 
-MULTI-WORKER SOLUTION:
-  To deploy BanGUI with multiple workers (e.g., via gunicorn -w 4), you must:
-    1. Replace RuntimeState with a shared store (Redis, shared memory, database).
-    2. Replace InMemorySessionCache with RedisSessionCache (see session_cache.py).
-    3. Ensure all workers use the same backend for coordination.
-
 SINGLE-WORKER ENFORCEMENT:
-  See TASK-002 in Docs/Tasks.md for deployment configuration that enforces
-  single-worker mode, preventing this issue entirely.
+  BanGUI enforces single-worker mode at startup:
+    1. Environment variable check: BANGUI_WORKERS must be 1 or unset
+    2. Database lock: Only one instance can run the scheduler at a time
+    3. Startup validation: Fails loudly if multi-worker scenario is detected
 
-For now, BanGUI is deployed as single-worker only — this constraint is
-acceptable and keeps the implementation simple.
+  See Docs/Architekture.md § Deployment Constraints for full details.
+
+MULTI-WORKER SOLUTION (Future):
+  To deploy BanGUI with multiple workers in the future (e.g., via gunicorn -w 4):
+    1. Replace RuntimeState with a shared store (Redis, shared memory, database)
+    2. Replace InMemorySessionCache with a shared backend (Redis, database)
+    3. Replace APScheduler with a distributed scheduler backend
+    4. Ensure all workers use the same backend for coordination
+
+CURRENT STATUS:
+  For now, BanGUI is deployed as single-worker only. This constraint is
+  acceptable and keeps the implementation simple. The database-backed scheduler
+  lock ensures only one instance runs background jobs, even in container
+  orchestration scenarios where multiple instances may start.
 """
 
 from __future__ import annotations