Decide whether the Python servers get a Streamable HTTP entry point #5125

Split out of #4853 (Spec Refactor Wave 2 Part 2: Modern-era Python servers), which named it a decision point and left it out of scope.

Question

Should fetch, git and time gain a Streamable HTTP entry point beside stdio, so they can be run remotely?

Context

• After Spec Refactor Wave 2 Part 2: Modern-era Python servers #4853, each server's serve() drives the SDK's dual-era Server.run() over stdio, serving 2026-07-28 and 2025-11-25 clients. mcp 2.x's low-level Server also offers streamable_http_app(), so the transport itself is little code.
• The cost is in what remote use means for each server:
  • git reads and writes the host's repositories; exposing it over HTTP needs an auth story and probably binding to localhost by default.
  • fetch is an SSRF surface; its private-address guard was built for a local process.
  • time is harmless remotely, but alone it hardly justifies the flag.
• everything already demonstrates Streamable HTTP for the reference set, and these are reference implementations, not products.

If yes

A --transport streamable-http (with host/port) option per server, the boot smoke in scripts/smoke-servers extended to it, HTTP tests in each server's tests/test_eras.py, and README configuration sections.

If no

Close it as not planned, and say in each README that the server is stdio-only by design.