feat(services): embed services list/enable/status in datumctl core

[scotwells]

What you get

datumctl services list, datumctl services enable <name>, and datumctl services status <name> — see which Datum Cloud services are available for your current project, request access to one, and check where a request stands (enabled, pending approval, denied, or not requested).

$ datumctl services list --project datum-cloud
NAME                   STATE         SINCE
AI Assistant           NotRequested
Billing                NotRequested
Compute                Active        46d ago
DNS                    NotRequested
IP Address Management  Active        15d ago
Network Services       NotRequested

These ship in datumctl core, the same way activity, ctx, and console do — no separate plugin install. That matters because plugins like compute already point users at datumctl services enable compute in their own error messages, so the command has to exist in the base binary for that guidance to work.

How it works

Wires the shared go.miloapis.com/service-catalog/pkg/cmd command group into the root command tree. The two scopes it spans have no single API serving both — Service lives only at the platform-wide root, ServiceEntitlement only inside a project's virtual control plane — so the command is given two lazy REST-config resolvers plus a lazy project resolver that reads live scope at RunE time (so a --project flag on the invocation is actually honored, rather than a value captured when the command tree was built). main.go routes the activation exit code through the existing top-level error path.

Replaces the draft SDK

This supersedes the draft service-activation SDK in #242 — the reusable logic now lives in service-catalog's pkg/activation + pkg/cmd and is imported rather than reimplemented here. #242 should be closed once this is confirmed good (handled separately).

Dependency / merge caveat

The service-catalog dependency is currently pinned to an unmerged, untagged commit (a002414) on milo-os/service-catalog#52. It will need re-pinning to a tagged release before this can merge — the same pin-chain sequencing this project has hit before (merge + tag service-catalog first, then re-pin here).

Related:

• feat(cmd): add pkg/cmd, the services CLI command group milo-os/service-catalog#52 — adds pkg/cmd, the services command group (the dependency this PR consumes; also carries the lazy-Project fix)
• Add pkg/activation: a shared SDK for service enablement milo-os/service-catalog#51 — pkg/activation, the shared enablement SDK underneath it

Verification

• go build ./..., go vet ./..., gofmt all clean.
• Manual smoke test against a live session: services list returns real entitlement state for a real project; --project <id> correctly overrides DATUM_PROJECT, confirming the lazy project resolver reflects flag precedence at RunE time (this was the bug the service-catalog side fixed); the no-scope case returns the expected "no project set" guidance.

🤖 Generated with Claude Code