docs: propose datumctl compute developer experience

[scotwells]

Summary

As we approach the launch of Datum Cloud compute, we want to make sure the CLI experience feels polished and developer-friendly from day one — not something bolted on after the fact.

This document proposes a datumctl compute command group designed around what developers actually do: deploy a workload, watch it roll out, check its health, get logs, and inspect instances when something breaks. The goal is to close the gap between "I have a container image" and "my workload is healthy across multiple cities" without requiring developers to understand the platform's internal resource model.

The proposal covers six workflows with example output for each:

• Deploy — flags, interactive, or manifest; saves a workload.yaml on first create; -y for CI pipelines
• Health — plain-English status with suggested next steps on failure
• Rollout — city-by-city progress with history and undo (20-revision default)
• Logs — workload-scoped by default, filtered by city/instance/container via the telemetry label system
• Instances — full project list with per-workload filtering
• Quota — project-level usage with city breakdown

Looking for feedback on the overall shape — whether the workflows match how the team expects developers to use the platform, and whether anything important is missing before this moves to implementation planning.

Test plan

• Review workflow examples for accuracy against the current platform model
• Confirm the quota scope (project-level, not per-city) matches the quota API
• Confirm log filtering via telemetry labels is achievable with the current telemetry stack