feat: Gate datumctl on per-org cloud-portal onboarding

[mattdjenkinson]

Summary

datumctl had no way to tell whether an organization had finished setup in the cloud portal. Milo already tracks that on each org via the OnboardingComplete condition, but datumctl never read it. Users could authenticate and hit API errors later with little guidance on what to do next.

This PR adds an onboarding check that runs only when a command targets a specific organization (active context, --organization, or --project). It fetches the org from the user control plane, the same path cloud-portal uses, and blocks org- or project-scoped work when onboarding is incomplete. The error message includes a portal link to that org's projects page, where the portal handles the rest of the redirect flow.

How each user path is handled

Situation	What happens
New user, no organizations	datumctl login saves credentials, discovers zero orgs, opens the cloud portal in the browser, and exits with a message pointing there. The landing page shows the portal URL if the session has no contexts. OAuth browser sign-in still redirects to the datumctl CLI docs after auth (unchanged).
Returning user, org ready	Login proceeds through context selection as today. Org- and project-scoped commands run normally. whoami and the landing page show onboarding as complete when a context is set.
Returning user, org not ready	Login saves credentials and runs discovery, but blocks selecting that org's context and prints the portal link (/org/{id}/projects). Scoped commands against that org are blocked with the same link. whoami and landing show incomplete status for the current context's org only.
Member of multiple orgs	Onboarding is checked per org. An incomplete org does not block commands against a complete org. Pick the ready context or pass --organization / --project for the org you want.
User-scoped commands, no org context	No onboarding gate. Commands like datumctl get organizations still work even if another org you belong to is mid-onboarding.
Platform-wide commands	Onboarding check is skipped (--platform-wide).
Service account login	Same org-scoped rules apply to whichever organization the machine account targets.

[scotwells]

At first glance, the error messaging used here is a little harsh and technical feeling. Can we make it more natural and human friendly?

[mattdjenkinson]

@scotwells good shout, updated!

[scotwells]

The messaging here still feels redundant and harsh. Maybe we should explain the recent changes we made to Datum that's now resulting in this error?

$ datumctl get organizations
error: Datum Technology, Inc. still needs setup: We couldn't tell if setup is finished yet.
Head to https://cloud.datum.net/org/datum/projects to finish up.

[scotwells]

Ah, I think I was running that against production, now I'm getting this:

$ datumctl get organizations
error: Scot Wells's Personal Org still needs your contact details before you can use datumctl here.
Head to https://cloud.staging.env.datum.net/org/personal-org-be933431/projects to finish up.

I still wonder if we should provide some context on the recent change we made, especially for older organizations that have been around awhile.

Should this also block users from doing the datumctl get organizations command? I would think allowing that command is helpful for users to see all of their organizations at a glance and we can show onboarding information there if the organization hasn't been setup fully.

[mattdjenkinson]

@scotwells i'm just trying to avoid hardcoding something that might not be really relevant in the long run? We're adding some help copy in the UI for existing orgs so that may be enough? Or we could link to a changelog article?

Regarding the get orgs command you're right, we shouldn't be blocking that. How does changing that list to something like this work? It will show which step the org is at in the onboarding process.

[scotwells]

@mattdjenkinson would "STATUS" be a better column name? Onboarding is very specific to first time use and not something that's useful after that.