[AI]: Introduce isolated `backend-ai` service in monorepo with independent build & CI pipeline

### Task Details

Create a new top-level `backend-ai/` service within the monorepo to isolate AI inference logic from the existing `backend/` API service. The new service must have its own dependency graph, Dockerfile, and CI pipeline. It must not share internal modules with `backend/` and must communicate strictly via HTTP using a defined API contract. The goal is to reduce backend image size, isolate ML dependencies, and prepare for independent scaling and future GPU deployment (if possible).

### Steps to Complete

1. Create `backend-ai/` directory at repository root.
2. Initialize separate `pyproject.toml` for AI service.
3. Implement minimal FastAPI application with health endpoint.
4. Define initial inference endpoints (e.g., `/summarize`, `/compare`, `/embed`).
5. Add independent Dockerfile for `backend-ai`.
6. Update `docker-compose.yml` to include `backend-ai` service.
7. Configure internal networking between `backend` and `backend-ai`.
8. Add environment variables for service URL configuration in `backend`.
9. Implement async HTTP client in `backend` for AI service calls.
10. Add CI workflow for `backend-ai` (lint, test, build).
11. Ensure no cross-imports between `backend` and `backend-ai`.
12. Validate container builds independently.
13. Update documentation to describe service boundaries and deployment model.

### Additional Notes

The AI service must remain stateless and should not directly access the primary database. All schema sharing should occur through explicit request/response models rather than shared internal modules. The architecture must allow future extraction into a separate repository with minimal refactoring.

Start by reading the existing backend service and docker-compose.yml, then map the requested new backend-ai/ service, its pyproject.toml, Dockerfile, and CI workflow boundaries. Review how backend configuration and HTTP calls are currently organized before defining the request/response contract. Done means the services build, communicate over HTTP, remain independently testable, and the deployment model is documented.

Written by the indexing model from the issue text.