Guardrails: Replace IP checks with security groups #176

Is your feature request related to a problem?
Guardrails rejects any request whose source IP is not an exact match in ALLOWED_IPS (check_source_ip, backend/app/api/deps.py:43), and production refuses to start if the list is empty (backend/app/core/config.py:110). kaapi-backend runs on ECS Fargate: one API task plus two Celery replicas, each with its own ENI IP that changes on every deploy and every replica replacement. Today only the API task IP is listed, so validator listing works but LLM-call guardrail checks (made from whichever Celery task runs the job) fail with 403 Source IP '...' is not permitted to access this service. about two times out of three. Every deploy, and every new client whose public IP must be whitelisted, means editing the env file and restarting guardrails. Network access control belongs at the network layer, not in application config.

Describe the solution you'd like

• Remove check_source_ip and its Depends wiring from check_bearer_token / verify_caller in backend/app/api/deps.py.
• Remove ALLOWED_IPS and parse_ip_list from backend/app/core/config.py, including the production-startup check that requires it.
• Drop ALLOWED_IPS from .env.example, deployment.md, and backend/app/api/API_USAGE.md.
• Restrict inbound on the guardrails EC2 security group (port 8001) to the kaapi-backend ECS service security group as source, instead of individual IPs. Document the SG rule in deployment.md as the replacement control.
• Bearer token auth (AUTH_TOKEN) stays as the application-level check.

Comments: Interim unblock until this lands: add all three current ECS task private IPs (Tasks tab → task → Configuration → Private IP) to ALLOWED_IPS and restart guardrails. Breaks again on next deploy.