Add Pydantic AI plugin samples

[brianstrauch]

Summary

• add runnable Pydantic AI Temporal examples for chat, tools, stateless MCP, Workflow Streams, human approval, structured output, multi-agent handoff, and Logfire observability
• provide credential-free TestModel execution plus an optional Pydantic AI Gateway live mode
• register agents declaratively through PydanticAIWorkflow and PydanticAIPlugin
• use released Pydantic AI >=2.46.0,<3 and Beartype >=0.23.0,<0.24, with Logfire >=4.39,<5
• document agent-isolation sandboxes as unsupported by this integration

Validation

All 11 Pydantic AI tests pass on Python 3.10 (Pydantic AI 2.54.0) and Python 3.14 (Pydantic AI 2.55.0). Lint, formatting, type checks on both Python versions, and lockfile validation pass.

• uv run --group pydantic-ai pytest -q tests/pydantic_ai_plugin
• uv run --group pydantic-ai ruff check pydantic_ai_plugin tests/pydantic_ai_plugin
• uv run --group pydantic-ai ruff format --check pydantic_ai_plugin tests/pydantic_ai_plugin
• uv run --group pydantic-ai mypy --check-untyped-defs --namespace-packages pydantic_ai_plugin tests/pydantic_ai_plugin
• uv lock --check

[brianstrauch]

We can optionally wait for beartype and pydantic releases before merging so we're not pinning commits

[DABH]

Two issues reproduced locally: the documented live model is missing its provider dependency, and a second approval round leaves the workflow running after assertion failures. All 11 added tests pass.

[DABH]

[P2] Include the OpenAI extra required by live mode

A clean uv sync --group pydantic-ai does not install openai, since neither the mcp nor temporal extra includes it. Consequently the documented model="gateway/openai:gpt-5.2" fails before making a request: infer_model("gateway/openai:gpt-5.2") raises an ImportError asking for the OpenAI provider dependency. This affects the live path in every sample even when PYDANTIC_AI_GATEWAY_API_KEY is set. Include the openai extra in this dependency group so the advertised live commands work.

[DABH]

[P2] Handle additional approval rounds after resuming the agent

A resumed run can legitimately return another DeferredToolRequests, since delete_record remains available and still requires approval. For example, a model can request deletion of record 42, then request record 43 after receiving the first tool result. After the first approved tool runs, this assertion raises instead of exposing the next request. With the sample worker configuration, AssertionError repeatedly fails workflow tasks, leaving the execution running without a way to finish the next approval. Loop over deferred outputs until the agent returns a string, carrying forward the latest messages and clearing the decision for each new round.