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/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