Implement cloud-planner-proxy: AI planner routes through Cloud API

Implements all 19 tasks of the cloud-planner-proxy OpenSpec change:

- Cloud API: cloud.planner_config (CloudPlannerConfig, load/build helpers)
  reusing runtime.tool_calling_client provider clients (no new dependency
  needed -- device-cloud-platform already depends on device-agent-runtime).
- Cloud API: new host-scoped POST /internal/v1/hosts/{host_id}/planner/decide
  internal endpoint, reusing existing bearer auth; logs only metadata
  (host id, tool name, latency, error class), never prompt/screenshot
  content.
- Host Agent: new AI_PLANNER_TRANSPORT config (direct default | cloud) and
  host_agent/cloud_planner_client.py::CloudProxyToolCallingClient, a
  synchronous ToolCallingClient implementation (structural, not importing
  runtime) that calls the new endpoint via its own httpx.Client -- avoids
  bridging the async HostAgentClient across the worker-thread boundary
  that AIPlanner.plan() runs in (asyncio.to_thread in lease.py).
- Host Agent wiring: create_execution_factories()/_host_agent_planner()
  select the cloud-proxy client only when AI_PLANNER_TRANSPORT=cloud;
  direct/unset transport is unchanged (still the default).
- Tests: 22 new tests across Cloud API config, the new endpoint, the new
  client, and transport-selection wiring; full non-integration suite
  (492 tests) passes with no regressions.
- Docs: docs/CLOUD_DEPLOYMENT.md documents the cloud transport, its
  trade-offs, and the credential split between Host Agent and Cloud API.

proposal.md/design.md were corrected during implementation to reflect two
findings: no new anthropic/openai dependency is actually needed, and
CloudProxyToolCallingClient uses its own sync httpx.Client rather than a
new HostAgentClient method, per the thread-boundary reasoning above.

openspec/changes/cloud-planner-proxy/proposal.md

@@ -54,15 +54,20 @@ provider/model or rotate a key without touching any Host.
 ## Impact
 
 - `packages/cloud-platform/cloud` / `apps/cloud-api`: new internal API
-  route + request/response models, new provider/credential configuration,
-  and a new direct dependency on the `anthropic`/`openai` SDKs (currently
-  only the root Runtime package depends on them -- this is new dependency
-  and attack surface for the Cloud API).
-- `apps/device-host-agent`: new `HostAgentClient` method for the
-  planner-decide call, a new `ToolCallingClient` implementation
-  (constructed in the `host_agent` package, not `runtime`, to preserve the
+  route + request/response models, new provider/credential configuration.
+  No new package dependency: `device-cloud-platform` already depends
+  unconditionally on `device-agent-runtime` (which declares `anthropic`/
+  `openai`), so both SDKs are already present wherever the Cloud API runs --
+  confirmed by `uv run python -c "import anthropic, openai"` succeeding in
+  the workspace venv without any pyproject change.
+- `apps/device-host-agent`: a new `ToolCallingClient` implementation
+  (`host_agent/cloud_planner_client.py::CloudProxyToolCallingClient`,
+  constructed in the `host_agent` package, not `runtime`, to preserve the
   existing hexagonal boundary that forbids `runtime` from importing `cloud`
-  or `host_agent`), and a new transport configuration setting.
+  or `host_agent`) with its own synchronous `httpx.Client` (matching
+  `HostAgentEnrollmentClient`'s pattern, since `ToolCallingClient.decide()`
+  runs synchronously off the main event loop), and a new transport
+  configuration setting (`AI_PLANNER_TRANSPORT`).
 - `runtime/tool_calling_client.py`: no changes to the `ToolCallingClient`
   Protocol itself; the new implementation satisfies it structurally from
   outside the `runtime` package.