#15070 MCP stdio session readiness timeout still hardcoded at 30s with no settings override (configurability gap not addressed by #14161/#14214)

Bug Description

MCPSessionManager._create_stdio_session (src/lfx/src/lfx/base/mcp/util.py) guards session readiness with a hardcoded 30-second asyncio.wait_for, with no settings override anywhere. This sits right next to mcp_server_timeout (src/lfx/src/lfx/services/settings/groups/mcp.py, default 20s), which is a configurable setting covering the overall tool-list call on the same path.

#14161 / #14214 already fixed the resource-leak consequence of these two timeouts disagreeing (the outer 20s firing before the inner 30s could leak the spawned subprocess) — but that fix was explicit about scope, per the PR description: "It intentionally preserves the existing timeout budgets, avoiding a shorter cold-start window for MCP servers." The underlying configurability gap itself is still open: there is still no way to raise the STDIO session's own readiness budget past 30s, and no way to make it consistent with a custom mcp_server_timeout value in either direction.

Concretely, this still leaves a real failure mode for anyone with a slow-starting local MCP server (e.g. one with a heavier npx/node cold start): raising LANGFLOW_MCP_SERVER_TIMEOUT above 30s does not help, because the inner session-readiness wait still caps at the hardcoded value regardless of what the outer setting is configured to.

Reproduction

Configure an MCP server (stdio transport) with a cold-start time longer than 30s but shorter than a raised LANGFLOW_MCP_SERVER_TIMEOUT.
Set LANGFLOW_MCP_SERVER_TIMEOUT=60.
Attempt to connect.

Expected: the connection succeeds within the configured 60s budget. Actual: Timeout waiting for STDIO session ... to initialize at ~30s, regardless of the higher configured value.

Expected behavior

Expose the STDIO (and Streamable HTTP, which has the same hardcoded-30s pattern in _create_streamable_http_session) session-readiness timeout as a setting, ideally defaulting to (or derived from) mcp_server_timeout so the two stay consistent without requiring two separate values to be tuned in lockstep.

Who can help?

No response — related to the area fixed in #14161/#14214, tagging for visibility in case the same reviewers want it.