scale up

Right now this application is not going to scale for production:

1. Each in-flight job holds a temp git checkout + history buffer + LLM context. Rough envelope ~200–500 MB/job. 30 concurrent jobs → 6–15 GB
2. No bounded pool / queue. submit_review spawns an unbounded thread per call. A burst of 50 submissions makes 50 worker threads + 50 git subprocesses + 50 LLM streams simultaneously.
3. GIL contention on the single event loop. SSE replay/format, JSON parsing of streamed tokens, and history buffer maintenance all happen in Python under one process. At ~30 streams × hundreds of token chunks/sec, the async loop will visibly stall (heartbeats may even time out).
4. SQLite single connection + global write lock.
5. Cannot scale horizontally as-is. In-memory _jobs dict, in-memory SSE queues, and the per-process job ownership in _get_owned_job mean adding a second uvicorn worker breaks the app.
6. Disk / network for clones. 30 simultaneous shallow clones eat disk burst credits and outbound bandwidth.

Plan to scale up:

1. SQLAlchemy so we can use postgres
2. Bounded ThreadPoolExecutor + queue + 429 backpressure
3. Shared bare-repo clone cache + git worktree eliminates 30× cold-fetch storms.
4. Event-loop hygiene, wrap sync store calls in asyncio.to_thread, coalesce token-event cross-thread wakeups.