Backend pyproject.toml is desynced from the working .venv — clean uv sync/lock is unresolvable

[VforVitorio]

Symptom

uv run/uv sync/uv lock from src/telemetry fail to resolve:

• fastmcp==3.2.0 needs python-dotenv>=1.1.0 but pyproject pins python-dotenv==1.0.0.
• fastmcp==3.2.0 needs pydantic[email]>=2.11.7 but pyproject pins pydantic==2.5.0.
• …and the cascade continues.

Root cause

The committed .venv (which boots + serves telemetry fine) was never built from the current pyproject.toml. Nearly every exact pin is out of sync with what's actually installed and working:

pkg	pyproject pin	installed (working)
fastapi	==0.109.0	0.136.3
uvicorn	==0.50.0	0.40.0
pydantic	==2.5.0	2.12.5
python-dotenv	==1.0.0	1.2.2
fastf1	==3.4.0	3.7.0
numpy	==2.4.6	1.26.4
pandas	==2.2.0	2.3.3
httpx	==0.26.0	0.28.1
pytest	==8.4.2	9.0.3

Also realtime==2.0.5 and kaleido==0.2.1 are declared but NOT installed in the venv — so the venv is partial/divergent, not a faithful sync of this manifest.

Fix (proper, needs a dedicated pass — do NOT blind-push)

Rebuild the dependency set as a resolvable whole compatible with fastmcp==3.2.0:

1. Align the runtime pins to a coherent, fastmcp-compatible set (prefer >= lower bounds + let uv.lock pin exact, per uv's model — the all-== manifest is the anti-pattern that caused this).
2. Decide the fate of realtime/kaleido (unused? move to an extra? drop?).
3. uv lock → uv sync into a FRESH venv → boot the backend → run pytest (the CI test job) to validate, not just boot.
4. Land via PR so CI gates it.

Workaround (unblocks now)

Use the existing working venv without re-resolving:

.\.venv\Scripts\uvicorn.exe backend.main:app --port 8000
# or: uv run --no-sync uvicorn backend.main:app --port 8000