refactor(api-client): extract cloud task transport

[richardsolomou]

Problem

Cloud-task transport behavior needed a host-neutral API client before mobile could stop maintaining its own HTTP implementation.

Depends on #3616
Refs PostHog/posthog#76229

Changes

Phase 1 only: I added the existing cloud-task, automation, integration, sandbox, and run transport to @posthog/api-client, with normalization and contract tests. Mobile remains unchanged in this PR.

How did you test this?

• Full monorepo typecheck at this checkpoint
• Final stack: 711 shared, 153 API-client, 2,599 core, and 451 mobile tests

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 787451d.}

[richardsolomou]

• feat(mobile): add Codex task parity #3654
• refactor(mobile): finalize portability boundary #3642
• refactor(mobile): adopt shared interaction semantics #3641
• refactor(mobile): finish shared task and inbox adoption #3640
• refactor(mobile): adopt shared task runtime #3637
• refactor(core): extract shared presentation semantics #3635
• refactor(core): extract permission and composer semantics #3634
• refactor(core): extract repository integration semantics #3633
• refactor(core): extract portable cloud task engine #3608
• refactor(core): rename cloud task service as engine #3624
• refactor(core): extract cloud task policies #3623
• refactor(api-client): extract cloud task transport #3622 👈 (View in Graphite)
• refactor(shared): extract task contracts and model policy #3616
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Comments Outside Diff (1)

1. apps/mobile/src/features/tasks/stores/taskSessionStore.ts, line 1198-1204 (link)

   Resume drops permission mode

   When a terminal cloud task is resumed with a selected permission mode, this call omits runtimeAdapter; the shared serializer only emits initial_permission_mode when an adapter is present, causing the resumed run to use the backend's default permission behavior instead of the user's plan, accept-edits, or auto mode.

   Knowledge Base Used: api-client: the shared PostHog API client

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/mobile/src/features/tasks/stores/taskSessionStore.ts
   Line: 1198-1204
   
   Comment:
   **Resume drops permission mode**
   
   When a terminal cloud task is resumed with a selected permission mode, this call omits `runtimeAdapter`; the shared serializer only emits `initial_permission_mode` when an adapter is present, causing the resumed run to use the backend's default permission behavior instead of the user's plan, accept-edits, or auto mode.
   
   **Knowledge Base Used:** [api-client: the shared PostHog API client](https://app.greptile.com/posthog-org-19734/-/custom-context/knowledge-base/posthog/code/-/docs/api-client.md)
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/mobile/src/features/tasks/stores/taskSessionStore.ts:1198-1204
**Resume drops permission mode**

When a terminal cloud task is resumed with a selected permission mode, this call omits `runtimeAdapter`; the shared serializer only emits `initial_permission_mode` when an adapter is present, causing the resumed run to use the backend's default permission behavior instead of the user's plan, accept-edits, or auto mode.

_{Reviews (1): Last reviewed commit: "Merge posthog-code/share-cloud-task-foun..." | Re-trigger Greptile}

[richardsolomou]

fixed the resume path so it always supplies the runtime adapter and preserves the selected permission mode.

[trunk-io]

😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details.