feat(cloud): add BYOC placement flags and the five missing cloud commands

[robertohluna]

A customer using the CLI could not use BYOC at all — they could not target their own cloud, and could not perform the one mandatory manual step in onboarding. compute_placement_request is fully wired server-side but was reachable only over raw HTTP or MCP.

Placement flags

--provider / --region-id / --pool-id / --host-id / --fallback on sandbox create, computers create and the top-level deploy (which is the deployment-create entry point — there is no separate create subcommand there).

Client-side validation is shape only: UUID format, provider among the four known values, fallback among the two, and --provider required once any placement flag is used, since normalize/1 has no default provider and omitting it always fails server-side.

The per-provider target rules are deliberately not duplicated — the server is authoritative and its error is surfaced. Worth recording what those rules actually are, since they are less obvious than they look:

provider	region_id	pool_id	host_id
miosa	empty	empty	empty
aws / gcp	UUID	UUID	empty
opencomputers	empty	empty	UUID

They are mutually exclusive, not optional. opencomputers is a separate product feature rather than a cloud provider, and its runtime adapter returns a hard error, so it is not presented as a normal choice.

Five missing endpoints

cloud capabilities · cloud accounts attach-gcp · cloud regions update · cloud pools update · cloud nodes certify

nodes certify is the important one — certification does not fire automatically, so until now the single mandatory manual step in BYOC onboarding was reachable only by hand-written curl. It auto-generates an idempotency key when omitted; the server requires one, and making every caller invent it is friction with no safety benefit since it stays retry-safe.

attach-gcp takes two service-account emails — actuator and worker, both required and required to differ. Building to the single-account shape that appears on the stale main of the server repo would have shipped a command that fails against the real API.

Note on scope

regions update and pools update expose a safe mutable subset, excluding tenant_id, cloud_account_id, provider, status and last_preflight_run_id — server-managed or dangerous, with no reasonable customer workflow needing them. Say if the full set should be exposed instead.

Engine.Cloud.attach_access_keys/3 remains routeless on the server — no route, no controller action — so it cannot be exposed here. Real gap, server-side.

Tests

425 passing, up from 419. Covers flag parsing, UUID validation, and that placement lands in the create body with a bad UUID rejected before any network call. typecheck and build clean.