🐛 Use current Starlette middleware conventions

[esnible]

Summary

Recent PR #201 broke the weather service.
I had tested it, but then CI asked me to update Starlette, which I did -- without re-testing.

(Optional) Testing Instructions

Run uv run --no-sync server in the a2a/weather_service directory. It fails before this change, it succeeds after it.
Or build from source with Kagenti and ask it about the weather.

[rubambiza]

Tested locally — confirmed the fix.

Without fix: AttributeError: 'Starlette' object has no attribute 'middleware'. Did you mean: 'add_middleware'?
With fix: Server starts cleanly on http://0.0.0.0:8000.

The migration from @app.middleware("http") to BaseHTTPMiddleware subclass is the correct pattern for Starlette 1.0.

Side note from testing: The breakage isn't reproducible on main alone because the lock file still resolves to starlette==0.46.2 (constrained by fastapi<0.48.0). It only manifests when the lock file is regenerated with the PR #201 dependency bumps, which pull in starlette==1.0.0. This means the lock file committed in #201 was likely regenerated after the pyproject.toml pin for starlette>=0.49.1 was added but the code wasn't re-tested against the new resolution — which matches what you described in the PR body.