fix(ai): fail at setup when an AI integration's client lacks capture_ai

[eli-r-ph]

💡 Motivation and Context

Stacked on #1046.

In 7.x, an AI integration given a client object without capture_ai sent its events through capture instead. In 8.0 that fallback is wrong in two ways:

• capture sends to /i/v1/analytics/events, not to /i/v1/ai/events, so the events skip the AI lane's 8 MiB size limit and its capture_ai_* settings.
• The failure surfaces late and differently per integration. For the OpenAI and Anthropic wrappers it happens after the provider call that the user already paid for, for streams at the end of the stream, for LangChain inside its callback manager, and for the agent processors at debug level, so in practice silently.

This PR removes the fallback and fails fast instead:

• A new _resolve_ai_client helper in posthog/ai/utils.py replaces every posthog_client or setup() in the integrations. It returns the given client or the global one, and raises TypeError when the client has no callable capture_ai.
• Every integration constructor uses it: the OpenAI, Azure OpenAI, Anthropic, Bedrock, Vertex and Gemini wrappers (sync and async), the LangChain CallbackHandler, and the OpenAI Agents and Claude Agent SDK processors. Gemini's own _resolve_posthog_client goes away.
• The send-time guards now check for capture_ai, not capture, and _capture_ai_event always calls capture_ai.
• A Client or AsyncPosthog instance, and the default global client, work as before.

Two behavior changes to call out for review:

• PostHogClaudeAgentProcessor(client=object()) used to build and then drop events silently. It now raises TypeError. The test that pinned the old behavior now asserts the error.
• The integration modules no longer import setup at module level, so the public API snapshot drops those incidental <module>.setup aliases and gains posthog.ai.utils.setup. A test that patches posthog.ai.<integration>.setup now gets an AttributeError, which is louder than a re-export that would silently stop taking effect. The repository's own two such tests now patch posthog.ai.utils.setup.

The migration guide's AI capture section and a changeset cover it.

💚 How did you test it?

• A parameterized test builds each of the 15 integration entry points with a client that has capture but no capture_ai. Each one raises TypeError at construction and never calls capture.
• The test that asserted the capture fallback is gone. The test stand-ins that only had capture now implement capture_ai.
• The 16 new or changed failure-path tests fail against the source of feat: exception level, keyword-only request args, uuid and geoip fixes #1046 and pass on this branch.
• ruff format --check, ruff check, mypy with the baseline filter, make public_api_check, and pytest --timeout=30 (4616 passed) all pass.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Cursor (Claude Opus 5.5). The reviewer chose to fail fast at construction over keeping the capture fallback or failing at send time, after the agent mapped how the failure would surface in each integration. The agent implemented it, removed the fallback test, and checked that no shipped client type lacks capture_ai.