Bump common.ai floor to pydantic-ai-slim>=1.71.0 and document capabilities passthrough

[kaxil]

Summary

Bumps the common.ai provider's pydantic-ai-slim floor from >=1.34.0 to >=1.71.0 -- the first release that ships the pydantic_ai.capabilities module (Thinking, WebSearch, ImageGeneration, MCP, etc.).

Users can now pass capabilities through AgentOperator(agent_params=...) without operator-level support landing first. A new example DAG (example_agent_capabilities.py) shows three patterns: Thinking alone, WebSearch alone, and composition with SQLToolset. The agent.rst guide gains a "Capabilities (pydantic-ai)" section.

Why this floor (1.71.0, not 1.100.0)

Capabilities first ship at 1.71.0. Anything earlier doesn't have pydantic_ai.capabilities and would fail to import the new example DAG. The "obvious" choice -- bumping to 1.100.0 (the V2-prep cutoff) -- was rejected for three reasons:

1. Avoids a fastmcp major bump for users with the [mcp] extra. Between 1.71 and 1.100, pydantic-ai's mcp extra switches from mcp>=1.25 to fastmcp-slim[client]>=3.3 -- a 2.x → 3.x major. Stopping at 1.71 keeps the existing mcp API.
2. Avoids a flood of V2-prep deprecation warnings for users who write their own pydantic-ai code in DAGs. Deprecations marked between 1.71 and 1.100 (e.g. Usage, request_tokens / response_tokens, stream_responses, MCPServerHTTP, GeminiModel, OpenAIModel) would otherwise start surfacing in their task logs.
3. Defers the pydantic-ai 2.0 migration to a separate PR with its own ramp.

The pydantic>=2.12 floor that pydantic-ai 1.71 requires is also imposed by anything later -- not avoidable if we want capabilities at all.

Behavior changes

For users on the [mcp] extra: no change (still mcp>=1.25, no fastmcp).
For everyone else: pydantic-ai-slim resolves to 1.71+ on fresh installs. Existing pinned environments are not forcibly upgraded -- this is a floor bump, not an upper-bound change.

Capabilities and serialization

agent_params is a templated field. Airflow serializes template fields by calling str() on values it doesn't natively understand, so live capability instances do not round-trip through SerializedDAG. The example DAGs and the .. warning:: block in agent.rst reflect this: capabilities are constructed inside the @dag function, not at module level, and a first-class capabilities= kwarg on AgentOperator (with serializer hooks) is filed as a follow-up on the AIP-99 project board.

Follow-ups

Tracked as draft items on AIP-99 Common Data Access Pattern + AI:

• Promote capabilities= to a first-class kwarg on AgentOperator / LLMOperator
• Decide OpenAI default once pydantic-ai 2.0 flips openai: to Responses API
• Rewrite LoggingToolset as a Logging capability
• Reframe HITL Review as a HITLReview capability
• Build AirflowBudget capability for cost/token controls
• Migrate CachingToolset / CachingModel durability to an AirflowDurability capability