Default FastMCP transport to stateless HTTP

[chaewon-huh]

Problem

• WidgetMCPServer only enabled stateless_http=True when OAuth was configured. The common dev path (fastapps dev without auth) left FastMCP in stateful mode.
• ChatGPT (or any Apps SDK client) holds on to the original Mcp-Session-Id cookie. When the developer restarts FastApps on the same URL, FastMCP’s session table is empty but the client still sends the stale cookie.
• FastMCP rejects the very first POST /mcp before our initialize_handler runs and returns HTTP 400. The only way to recover is to delete and re-add the MCP server, which kills the iteration loop and makes the DX terrible.

Solution

• Always instantiate FastMCP with stateless_http=True, regardless of whether auth is configured.
• Stateless transport matches how Apps SDK clients reconnect after restarts and mirrors FastApps’ architecture (widgets are stateless per invocation, auth is JWT-based, and no sticky state lives in memory).

Testing

• fastapps dev → register server in ChatGPT → open a widget → restart fastapps dev without touching ChatGPT → refresh. With this change, the client cleanly re-runs initialize/list_tools without 400s or re-registration.

[Jhvictor4]

Perfect improvement! Thanks for contributing.
This will make FastApps compatible with serverless environments as well.