fix: recognize typing_extensions.TypedDict input schemas on Python 3.11+

[redswimmer]

Fixes #1337

Problem

On Python 3.11+, the SDK uses stdlib typing.is_typeddict, which returns False for classes built on typing_extensions.TypedDict (a separate implementation since typing_extensions 4.6). _build_input_schema then falls through to {"type": "object", "properties": {}}, so the tool reaches the model with no parameters and no warning. 3.10 is unaffected because it already uses typing_extensions.is_typeddict.

class Args(typing_extensions.TypedDict):
    latitude: Annotated[float, "Latitude coordinate"]

@tool("probe", "probe", Args)
async def probe(args): ...

_build_input_schema(probe)  # 3.11+: {"properties": {}, "type": "object"}

Fix

• Import is_typeddict from typing_extensions on every Python version; it accepts both TypedDict spellings.
• Make typing_extensions an unconditional dependency, since the SDK now imports it on every version. Raise the floor from 4.0.0 to 4.1.0: is_typeddict doesn't exist in 4.0.0, so the old floor also broke the import on 3.10. mcp/pydantic already require a newer version, so resolved installs don't change.

Verification

Ran the reproduction script from the issue with typing_extensions 4.16.0:

Python	before	after
3.10	✅ full schema	✅ full schema
3.11 / 3.12 / 3.13	❌ empty schema	✅ full schema, required: ["latitude"]

• New test_typeddict_schema_for_either_typeddict_spelling registers a tool through create_sdk_mcp_server, reads the schema back via list_tools, and covers both spellings, Annotated, NotRequired and a nested TypedDict. It fails on main (assert {} == {...}) and passes with the fix.
• pytest on 3.10–3.13: all pass · mypy: clean · ruff: clean

[sigley]

Validated exact head d433bf6 independently. On current main, a typing_extensions.TypedDict input schema reproduces as an empty object schema; this head recognizes the same class and emits the expected typed properties/required set. The branch merges cleanly with current main, the targeted TypedDict cases pass 6/6, the full MCP integration slice passes 146/146, and compile/diff checks are clean. One non-blocking integration note: if #1325 lands first, the pyproject conflict should preserve its AnyIO 4.5 floor while keeping this PR's unconditional typing_extensions>=4.1.0 requirement.