feat: deprecate the sse transport in favor of Streamable HTTP

[AutomateIP]

Summary

Marks the sse transport as deprecated and steers new deployments toward the
Streamable HTTP transport (--transport http). No behavior in the transport
dispatch changes — this adds a one-time startup warning plus documentation
updates only.

Changes

• Add a one-time logging.warning(...) in Server.run(), guarded by
  transport == "sse", pointing users at --transport http.
• Update the --transport CLI help text and the config field description
  (the Literal["stdio","sse","http"] choices are unchanged).
• README: consolidate to a single sse example labeled deprecated; make http
  the recommended web transport throughout.
• Update docs/mcp.conf.example accordingly.
• Add 3 tests: warning fires exactly once on sse, no warning on http/stdio.

Note on sse vs. http routing (intentional, not an oversight)

A conformance audit found that sse and http are wire-indistinguishable in
this server today: both resolve to the same self.mcp.http_app() call with no
transport= kwarg distinguishing them, and both already emit spec-compliant
Streamable HTTP output. The explicit decision here is NOT to change that
routing — only to add the deprecation warning on top. This was empirically
validated live: a legacy HTTP+SSE client gets a 404 against this server, while
a Streamable HTTP client connects via either --transport value. The dispatch
code is byte-for-byte unchanged in this PR.

Testing

• Unit tests pass (make ci, 2836 passed)
• Integration tests pass — verified against a live Itential Platform:
  warning fires once on sse with exact text; no warning on http/stdio;
  both sse and http transports function end-to-end (real get_health via a
  real MCP client); live OAuth unaffected; legacy-SSE client 404s while
  streamable-HTTP connects via either transport value.

Related Issues

WI-2 / G9 (0.14.0 decision table, Tier C #4 / Tier D1 #22).