feat: add an AI capture lane to AsyncPosthog

[eli-r-ph]

💡 Motivation and Context

Stacked on #1027. The sync Client sends $ai_* events on a separate AI lane, but AsyncPosthog has only the analytics lane. This PR gives AsyncPosthog the same AI lane, with the same options and defaults.

Changes

• New AsyncPosthog.capture_ai (queued) and capture_ai_immediate (awaits delivery), both posting to /i/v1/ai/events.
• New options with the sync defaults: capture_ai_compression, capture_ai_max_queue_size (1000), capture_ai_timeout (30 s) and capture_ai_max_event_bytes (8 MiB, can only be lowered).
• The AI lane has its own queue and workers, which start on the first capture_ai call.
• flush and shutdown drain both lanes.
• New privacy_mode and enable_full_ai_capture options, read by the AI wrappers as on Client.
• Size and queue-full logs name the lane.

With #1027, a wrapper given an AsyncPosthog client now sends to the AI endpoint.

💚 How did you test it?

• Tests cover each lane's path, compression, timeout and size cap, and that flush and shutdown deliver both lanes.
• Privacy tests run on both clients.
• Breaking each behavior on purpose fails a test.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Cursor (Claude Opus) under the direction of the assignee.

🤖 Generated with Claude Code

[eli-r-ph]

@greptileai review

[dustinbyrne]

The async lane and both-lane lifecycle handling look consistent with the sync implementation. One minor, non-blocking malformed-input exception-boundary issue is noted inline. Consider ensuring the stack’s spec update and migration guide explicitly cover default async-wrapper routing to the AI endpoint.

AI-assisted review.