feat(agent): let the assistant create workloads

[scotwells]

What a customer gets

Until now the assistant could only explain why a workload was broken. This PR lets it help create one, without the customer needing a shell or knowing the Workload API.

A customer can now ask Patch "deploy my image to Dallas" and have the assistant discover what the project may use, draft a valid manifest, check it against the platform before anything is created, show the customer exactly what will change, and only then apply it. Every step runs as the customer, and the assistant cannot apply anything it has not first shown them.

Discovery. Four new read-only tools answer the questions a first deploy stalls on: compute_locations_list (where compute is offered and this project can use it, resolved from compute's own ServiceAvailability records), compute_networks_list, compute_quota_get (limit, used, available), and compute_instance_types_list. Nothing to guess and no submit-and-read-the-error loop.

Draft and check. compute_workload_render turns a handful of inputs (image, location, replicas, port, env, ConfigMap and Secret mounts, public IPv4, VM) into a complete manifest, and tells the customer in plain words which choices cannot be changed after create. compute_workload_validate runs the real server-side dry-run and returns the exact rejection as a field error. Both write nothing.

Plan, confirm, apply. compute_workload_plan validates, reports create vs update, shows the diff, says whether the network will be created, and mints a token bound to that exact manifest, project, and object version. compute_workload_apply only accepts a manifest whose token still matches. Edit one character, wait past fifteen minutes, or let someone else change the workload first, and it refuses and asks the assistant to re-plan. A refusal is the check working.

A skill to drive it. workload-create walks the assistant through prerequisites, the container-vs-VM choice, the input list, the traps in customer language (one instance type today, name vs secretName, every volume must be attached, IPv6-only by default, SSH keys for VMs, ConfigMap size limits), and the render, validate, plan, confirm, apply, diagnose sequence. It is written API-first; datumctl appears only as an optional aside for customers who have a shell.

Also in this PR

• Every tool is now prefixed compute_ so the assistant can compose tools from several services without collisions. The capability document must register the prefixed names.
• internal/workloadspec is the assistant's manifest renderer. The CLI keeps its own spec building for now (its flag surface moved on in Use canonical locations for compute placement #264 and feat(cli): publish workloads on a URL with --http-port #289); folding it onto the shared package is a follow-up.
• The instance type catalog is exposed from validation via SupportedInstanceTypes() so the tool and the webhook cannot disagree. Sizing is still duplicated pending Define an authoritative instance-type resource catalog (single source of truth for vCPU/memory) #137.
• Quota reading moved to internal/quotaview, shared by the CLI and the MCP server.

Verified against staging

Ran the server locally against datum-cloud on staging with a real session token, before and after merging main's move to location-named placements: all thirteen tools published; compute_locations_list returned us-central-1 and us-east-1 from the availability records; networks, quota, and instance types returned correct data; render emitted placements[].locations; validate accepted a good manifest and surfaced the webhook's exact rejection for an unknown location name; plan minted a token and reported the network state; apply refused a forged token and a tampered manifest, and the workload was confirmed absent afterwards. Apply was not run for real.

Follow-ups

• Update the assistant's capability document with the compute_ tool names and the workload-create runbook URL.
• Fold datumctl compute deploy's spec building onto internal/workloadspec so the CLI and the assistant render identical manifests.
• Set PLAN_TOKEN_KEY in the compute-mcp deployment so plan tokens validate across replicas.
• The manager gains ServiceAvailability as a locationSource but its default is still NetworkServices, so the webhook validates placements against LocationBindings while the tool reads availability records. Switch the manager in deployment config so the two cannot disagree.
• Placements use locations and locationSelector from Use canonical locations for compute placement #264; cityCodes is deprecated and not emitted by the renderer.
• Image building and log access remain outside what a hosted assistant can do.