Add opt-in CORS support to the MCP proxy

[lorenzozanee]

Summary

Browser-based MCP clients (for example MCP Inspector) cannot use the transparent MCP proxy endpoint: the browser's OPTIONS preflight is forwarded to the backend MCP server, which answers 405 Method Not Allowed, and proxied responses carry no Access-Control-Allow-* headers, so the browser blocks them with a CORS error.

This adds opt-in CORS support to the proxy. Setting --allowed-origins on thv proxy or thv run enables CORS for exactly those origins:

• OPTIONS preflights from an allowed origin are answered by the proxy with 204 and never reach the backend.
• Access-Control-Allow-Origin (the matched origin), Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Expose-Headers, and Vary: Origin are injected on matching responses.
• The allowlist is the same explicit list already enforced by the Origin-header validation middleware, so CORS never widens access: an origin that passes preflight is exactly an origin that passes request-time Origin validation. There is no wildcard and no reflection of arbitrary origins.
• CORS stays disabled by default and is a no-op when no origins are configured.

Access-Control-Allow-Headers includes MCP-Protocol-Version (ToolHive reads and validates it on the request path) and Last-Event-ID (used for SSE stream resumption).

Fixes #4297

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• Unit tests (task test)
• E2E tests (task test-e2e)
• Linting (task lint-fix)
• Manual testing (describe below)

Unit tests cover the new middleware (preflight 204 + headers for an allowed origin, no CORS when no origins are configured, exact-match only) and the proxy wiring (OPTIONS answered by the proxy instead of the backend 405; disallowed origins still 403 from Origin validation). Manually verified against a running proxy: an allow-listed origin now receives 204 + Access-Control-Allow-Origin on preflight and 200 + headers on the real request, while the default configuration keeps the previous backend 405 behavior.

Changes

File	Change
pkg/transport/middleware/cors.go	New CORS middleware (exact-match allowlist, OPTIONS 204, header injection)
pkg/transport/middleware/cors_test.go	Middleware unit tests
pkg/transport/proxy/transparent/transparent_proxy.go	WithAllowedOrigins option; CORS applied outermost in Start(); shared method constants
pkg/transport/proxy/transparent/cors_test.go	Proxy-level CORS integration tests
cmd/thv/app/proxy.go	Enable CORS from --allowed-origins on thv proxy
cmd/thv/app/run_flags.go	Enable CORS from --allowed-origins on thv run
pkg/transport/middleware/origin/origin.go	Export CanonicalizeOrigin for shared matching
pkg/transport/types/transport.go	AllowedCORSOrigins transport config field
pkg/transport/http.go, pkg/transport/factory.go	Thread CORS origins through the HTTP transport
pkg/runner/runner.go	Pass the explicit origin allowlist to the transport
docs/cli/thv_proxy.md, docs/cli/thv_run.md	Regenerated CLI docs

Does this introduce a user-facing change?

Yes. --allowed-origins on thv proxy and thv run now also enables CORS for the listed origins on the MCP proxy endpoint, so browser-based clients (e.g. MCP Inspector) can connect. When the flag is omitted, behavior is unchanged: CORS stays disabled. Operators who handle CORS at an upstream gateway can keep omitting the flag.