Add Kubernetes liveness/readiness probes and middleware order validation

- Split /health into /health/live (liveness) and /health/ready (readiness)
  following Kubernetes conventions. Combined /health retained for backward
  compatibility with existing Docker HEALTHCHECK definitions.
- Add ReadyCheck and ReadyResponse models for structured readiness output.
- Add _assert_middleware_order() startup check enforcing:
  RateLimit → Csrf → CorrelationId middleware chain.
- Register CorrelationIdMiddleware, CsrfMiddleware, RateLimitMiddleware
  in create_app() with documented required order (reverse of processing).
- Add correlation.py, csrf.py, rate_limit.py middleware modules.
- Add health probe tests in test_health_probes.py.
- Update test_main.py with middleware order assertion tests.
- Update frontend useFetchData hook tests.
- Docs: update Deployment.md with Kubernetes probe config examples.

backend/app/middleware/correlation.py

@@ -11,6 +11,18 @@ Correlation IDs flow through the request lifecycle:
 3. Middleware stores in structlog.contextvars
 4. All log entries include the correlation ID automatically
 5. Error responses include the correlation ID for client-side correlation
+
+Processing order
+-----------------
+This middleware must be the outermost in the security-critical chain so it
+executes first on incoming requests (outermost = first to see request,
+last to see response). In the required chain:
+
+    CorrelationIdMiddleware → CsrfMiddleware → RateLimitMiddleware
+
+The registration order in ``main.py`` must be:
+    RateLimitMiddleware, CsrfMiddleware, CorrelationIdMiddleware
+(last registered = outermost in Starlette's reverse application).
 """
 
 from __future__ import annotations

backend/app/middleware/csrf.py

@@ -9,6 +9,16 @@ is not CSRF-vulnerable. GET, HEAD, and OPTIONS requests are also exempt.
 
 Cross-site requests cannot set custom headers without CORS preflight, which the
 backend rejects for non-allowed origins, providing defense-in-depth.
+
+Processing order
+----------------
+This middleware must be the middle component in the security-critical chain:
+
+    CorrelationIdMiddleware → CsrfMiddleware → RateLimitMiddleware
+
+It runs after CorrelationIdMiddleware has attached a correlation ID (so rate-limit
+errors can include it in their log context), and before RateLimitMiddleware
+(so rate-limit counters are only incremented for requests that pass CSRF checks).
 """
 
 from __future__ import annotations

backend/app/middleware/rate_limit.py

@@ -20,6 +20,16 @@ scheduler lock). The startup warning log documents this constraint.
 Redis-backed adapter that uses atomic INCR + EXPIRE semantics. The
 check_allowed() and check_allowed_for_bucket() interfaces are designed
 to make this swap-in without touching middleware or router code.
+
+Processing order
+----------------
+This middleware must be the innermost in the security-critical chain:
+
+    CorrelationIdMiddleware → CsrfMiddleware → RateLimitMiddleware
+
+Rate limiting is last so that requests blocked by CsrfMiddleware do not
+consume rate-limit budget, and so that rate-limit log entries (which are
+unusual and potentially suspicious) always carry a correlation ID for tracing.
 """
 
 from __future__ import annotations