platform/locations: generate Regions table from Locations API instead of hand-typed Markdown

[felixwidjaja]

Overview

platform/locations.mdx has a "Regions" table listing Datum's entire global footprint (region code + metro area) that is hand-typed Markdown. It's a second, independent copy of the same data that lives in src/data/locations.json over in datum-cloud/datum.net (see datum-cloud/datum.net#1692), so the two are already prone to drifting from each other and from reality.

Current state

## Regions

| **Region Code** | **Metropolitan Area** |
| --- | --- |
| ae-north-1 | Dubai |
| au-east-1 | Sydney |
...

This table is maintained by hand. The page already documents the project-scoped way to check availability (datumctl get locations --project <project-id>), but the global table above it is not generated from anything — it's just prose.

Proposed fix

Generate the "Regions" table from the same Locations API / datumctl data source the website should move to (see datum-cloud/datum.net#1692), instead of maintaining it by hand in two places.

Open question: same as the website issue — is there a canonical project/scope where datumctl get locations (or the underlying locations.miloapis.com/v1alpha1 API) returns Datum's entire datum-managed footprint, rather than just what's visible inside one customer project? If so, the table can be regenerated from that (e.g. a docs build step, or a script + CI check that flags drift). If not, we should figure out what does hold the canonical global list before automating this.

Acceptance criteria

• Confirm the source of truth for the full global footprint (API scope, or datumctl invocation) that this table should be generated from.
• "Regions" table is generated/synced from that source rather than hand-typed, with a documented regeneration step.
• Adding/renaming/removing a region no longer requires manually editing this table.
• Consider linking/consistency-checking against the same source used by datum.net/locations so the two never disagree.