## Implementation Plan

**Root cause:** Pre‑0.20.1 versions of Starlette’s `GZipMiddleware` compress the response body but do **not** update the `Content‑Length` header. The project pins `fastapi` and `starlette` without any version constraints, so any install can pull a broken version.

**Fix (Option A – zero code risk):** Add minimum version constraints in `pyproject.toml` to guarantee the fixed GZipMiddleware is always present. No application code changes required.

---

### Steps

1. **Open** `pyproject.toml`  
2. Locate the `dependencies` section (or `[project.dependencies]`).  
3. Change the bare entries:
   - `fastapi` → `fastapi>=0.110.0`
   - `starlette` → `starlette>=0.37.0`  
4. **Save** the file. No other files are touched.  

*(These versions include the `Content‑Length` recalculation fix from Starlette PR #1579 merged in v0.20.1, and FastAPI v0.110.0 depends on a compatible Starlette.)*

---

### Verification / Definition of Done

- [ ] The **test command** `pip install -e '.[dev]' -q && make test-unit` completes with exit code 0 and produces no test failures.
- [ ] The **lint command** `pip install -q ruff && ruff check .` reports zero new errors (pre‑existing issues outside the change are acceptable).
- [ ] `pip freeze | grep -E '^(starlette|fastapi)='` shows version ≥0.37.0 for `starlette` and ≥0.110.0 for `fastapi`.
- [ ] `git diff --stat` confirms exactly one file modified (`pyproject.toml`), with only the two version pin changes.

The bug is fixed at the dependency level: any fresh install or rebuild will pull a Starlette version that correctly recalculates `Content‑Length` after GZip compression.