[Feature]: Extend support for Python 3.10 for aws-strands integration

[Vishal0203]

Pre-flight Checklist

• I have searched existing issues and this hasn't been requested yet.

Problem or Motivation

Our enterprise has its Python version locked to 3.10, but ag_ui_strands declares:

requires-python = ">=3.12, <3.14"

so installation fails outright on 3.10. We currently patch the package locally to make it work in our environment, which means carrying a fork and re-applying the patch on every upgrade. It would be great if it worked out of the box.

Worth noting the package's own README has advertised 3.10 support since the integration first landed:

integrations/aws-strands/python/README.md

## Prerequisites

- Python 3.10+

That line was added in #675 (dae7c941) — the same commit that set requires-python = ">=3.12". So the documented contract and the enforced metadata have disagreed from day one, and 3.10 users only discover it at install time.

aws-strands is also the only Python integration in the repo with a 3.12 floor — every other one is at 3.10 or 3.11:

Integration	requires-python
langgraph	>=3.10,<3.15
adk-middleware	>=3.10, <3.15
agent-spec	>=3.10,<3.14.0
langroid	>=3.10, <3.14
crew-ai	>=3.10,<3.14
watsonx	>=3.10, <3.15
sdks/python	>=3.9
sdks/python/a2ui_toolkit	>=3.10,<3.15
claude-agent-sdk	>=3.11
claude-managed-agents	>=3.11
aws-strands	>=3.12, <3.14

Proposed Solution

Extend support for Python 3.10 on the ag_ui_strands package by lowering the floor:

requires-python = ">=3.10, <3.14"

The upper bound stays at <3.14 — this only lowers the floor, nothing else changes.

Nothing in the adapter actually requires 3.11+:

• Syntax — every file under src/, tests/, and examples/ parses with ast.parse(..., feature_version=(3, 10)). The only modern constructs are PEP 604 unions (X | None), which are 3.10+ at runtime. No match statements, StrEnum, TaskGroup, ExceptionGroup / except*, itertools.batched, typing.Self, @override, datetime.UTC, or tomllib.
• Dependencies — all already support 3.10: strands-agents is >=3.10 (classified 3.10–3.13), ag-ui-a2ui-toolkit is >=3.10,<3.15, ag-ui-protocol is >=3.9. Nothing in the tree forces 3.12.

Scope of the change:

• pyproject.toml — requires-python = ">=3.10, <3.14"
• examples/pyproject.toml — python = "<3.14,>=3.10"
• examples/README.md — state the supported range as 3.10 – 3.13
• uv.lock — regenerate; picks up the 3.10 backports (exceptiongroup, tomli, backports-asyncio-runner) behind python_full_version < '3.11' markers, so 3.11+ resolution is unaffected

No CI changes needed: no workflow pins a Python version for this package, and build-python-preview only runs uv build.

Alternatives Considered

• Patching the package locally (what we do today) — works, but means maintaining a fork and re-applying the change on every release. Doesn't help anyone else hitting the same wall.
• Vendoring the adapter into our own codebase — drops us off the upstream release train entirely and we'd miss fixes.
• Upgrading our enterprise Python to 3.12 — not under our control in the near term; the 3.10 pin is an org-wide platform constraint.
• Backporting via typing_extensions shims — unnecessary. The code doesn't use any 3.11+ features, so there's nothing to shim; the floor is simply stricter than the code requires.
• Fixing only the README to say 3.12+ — this would resolve the documentation inconsistency but leaves 3.10 users blocked, which is the actual problem.

Additional Context

PR: #2285

Verified on CPython 3.10.20 with the floor lowered:

• uv sync --python 3.10 --frozen --all-groups — resolves and installs cleanly
• import ag_ui_strands — all 20 public exports load
• pytest tests/ — 176 passed, 2 skipped
• poetry install in examples/ on a 3.10 interpreter, then import server.__main__ — OK
• uv build — resulting wheel reports Requires-Python: <3.14,>=3.10

One incidental find while regenerating the lock: uv lock --check already fails on main before any of this, because the committed pyproject.toml requires ag-ui-a2ui-toolkit>=0.0.4 while uv.lock still pins 0.0.3. Regenerating fixes it as a side effect — happy to split that into its own PR if maintainers prefer it separate.