fix: unblock the MCP session, and authenticate to the AI gateway with OIDC

Two things, both discovered by instrumenting the failure rather than trusting
the message it printed.

The MCP session never failed on protocol. macOS resolves any `.local` name
through mDNS first and takes a flat ~5.0s doing it, which sits exactly on
httpx's 5s default connect timeout; fastmcp reported the resulting
ConnectTimeout only as "Failed to initialize server session". Earlier tests
used `curl --resolve`, which bypasses DNS entirely and made it look like DNS
had been eliminated. Settings.http_timeout (60s) now covers the shared client,
the client fastmcp builds, and MCPToolset's init_timeout. list-products,
get-product and create-product now enumerate over the real gateway.

Inference used a static "unused" api_key against a gateway whose
openid-connect plugin requires audience ["llm-proxy"]. The model call now
carries a token exchanged for llm-proxy-audience, so it is attributable to the
same (agent, end user) pair as every tool call.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

pyproject.toml

@@ -17,6 +17,9 @@ dependencies = [
     # OpenAI protocol, [mcp] for the MCP client.
     "pydantic-ai-slim[openai,mcp]>=2.35.3,<3",
     "httpx2>=2.12.0,<3",
+    # httpx 0.x as well, and not redundantly: fastmcp builds its own
+    # transport client and hands us an httpx.AsyncClient to configure.
+    "httpx>=0.28.1,<1",
     "pydantic-settings>=2.7",
     "uvicorn>=0.52.4",
 ]