feat: AsyncPosthog AI capture lane

[eli-r-ph]

💡 Motivation and Context

• The sync Client has a separate AI lane: capture_ai posts to /i/v1/ai/events with its own queue, compression, timeout and 8 MiB event cap (feat!: send capture through v1 by default; capture_ai to /i/v1/ai/events #1017, feat: AI lane config and size-aware batching #1022).
• AsyncPosthog has only the analytics lane. An async user has no way to send a large $ai_* event to the AI endpoint.

This PR gives AsyncPosthog the same AI lane, with the same knobs and defaults as the sync client.

Changes

• New methods: AsyncPosthog.capture_ai (queued) and capture_ai_immediate (awaits delivery). Both post to /i/v1/ai/events.
• New constructor options, with the sync client's defaults and validation:
  • capture_ai_compression (default none; the env var does not apply)
  • capture_ai_max_queue_size (1000)
  • capture_ai_timeout (30s)
  • capture_ai_max_event_bytes (8 MiB; it can only be lowered)
• Each lane has its own queue, consumers, endpoint, size cap, timeout and compression. The AI lane starts its workers on the first capture_ai call, not before.
• flush wakes both lanes before it waits on either, so one lane's partial batch does not sit out its flush_interval. shutdown stops and awaits the workers of both lanes.
• New privacy_mode and enable_full_ai_capture options, read by the AI wrappers the same way as on Client. Without them, a wrapper given an AsyncPosthog client always truncated and redacted media.
• Size-drop and queue-full logs name the lane and endpoint.
• The v1 send helpers and the local requests stub type timeout as float, so the 30s float AI timeout type-checks end to end.

Note

With #1027, the AI wrappers call capture_ai on any client that has it. A wrapper given an AsyncPosthog client now sends to the AI endpoint, where it used to fall back to capture.

💚 How did you test it?

• test_capture_immediate_uses_its_lane_without_building_httpx_client checks that each immediate method uses its own lane's path, compression and timeout.
• test_ai_events_queue_on_their_own_lane_and_flush_drains_both:
  • the AI lane stays idle until capture_ai
  • flush delivers both lanes
  • a queued AI event above the analytics cap is sent
  • shutdown delivers a later AI event and clears every worker
• test_capture_immediate_applies_its_lane_size_cap_after_before_send covers the analytics cap, the larger AI cap, and a lowered AI cap.
• test_rejects_invalid_batch_settings adds the three AI options.
• TestCaptureAiPrivacyMode runs on both clients: privacy_mode strips content even with full capture on, and enable_full_ai_capture alone decides media redaction.
• Break-on-purpose, each with a failing test:
  • capture_ai on the analytics lane
  • flush draining only the analytics lane
  • the consumer ignoring the lane size cap
  • capture_ai_immediate using the analytics timeout
  • AsyncPosthog not storing privacy_mode, or not storing enable_full_ai_capture
• The public API snapshot is updated for the new options and methods.

📝 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

Covered by the existing capture-v1-major changeset; the migration guide lands later in this stack.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Written with Cursor (Claude Opus) under the direction of the assignee. Skills used: writing-tests, writing-pr-descriptions.

Agent calls worth review:

• Lane state moved into a small _AsyncLane holder instead of parallel attributes per lane, to mirror the sync client's _Lane.
• AsyncPosthog gets privacy_mode and enable_full_ai_capture here, not in a follow-up. It does not get the sync client's deprecated _use_ai_lane / _enable_multimodal_capture aliases, since async never had them.