fix(deps): pin patched Starlette for CVE-2026-48710

[EvolvingSoftwareAgent]

Summary

• Pin Starlette 1.2.0 directly in the web, mcp, computer-use, and dev extras.
• Regenerate uv.lock so locked installs resolve Starlette 1.2.0 instead of the vulnerable pre-1.0.1 line.
• Keeps Hermes' exact-pin policy while preventing FastAPI/MCP transitive installs from resolving a vulnerable Starlette for CVE-2026-48710 / BadHost.

Security context

Starlette versions before 1.0.1 are affected by CVE-2026-48710 ("BadHost"), where crafted Host headers can poison reconstructed URL paths used by path-based authorization checks. Hermes already has Host-header and defense-in-depth work in the dashboard path, but installs should also avoid vulnerable Starlette versions at dependency resolution time.

References:

• Ars Technica: https://arstechnica.com/information-technology/2026/05/millions-of-ai-agents-imperiled-by-critical-vulnerability-in-open-source-package/
• CVE: https://www.cve.org/CVERecord?id=CVE-2026-48710
• Prior defense-in-depth PR: security: CVE-2026-48710 BadHost defense-in-depth — use raw ASGI path in auth middleware #34162

Closes #35067

Test plan

• uv lock --check
• Python dependency assertions for starlette==1.2.0 in dev, mcp, computer-use, and web extras
• scripts/run_tests.sh tests/hermes_cli/test_web_server_host_header.py

[teknium1]

Superseded by #35118 (merged as 0437137), which closes the same CVE-2026-48710 (BadHost) — thanks for catching this and filing both the issue (#35067) and a fix so fast, @EvolvingSoftwareAgent.

We landed #35118 as the canonical fix because it carries the same Starlette pin across all four server-surface extras (web/mcp/computer-use/dev) plus two things this PR didn't: it mirrors the pin into tools/lazy_deps.py tool.dashboard (otherwise an on-demand hermes dashboard install would re-resolve Starlette unpinned), and it adds two CVE-floor regression guards in tests/test_packaging_metadata.py so a future dropped pin or stale lock fails in CI.

On the version: we pinned ==1.0.1 rather than 1.2.0. 1.0.1 is the advisory's named fix floor and the oldest patched release (~8 days of bake time vs ~1 day for 1.2.0) — our supply-chain policy prefers the most-baked patched release over the newest, since the newest is exactly the window a fresh malicious upload would land in. Both fully close the auth-bypass; the difference is bake time, not coverage.

Closing as superseded — the substance of your fix shipped.