🚀 Feature: Self-hosted multi-region console (region picker + runtime regions catalog)

### 🔖 Feature description

Console already has Cloud multi-region UX (region catalog, create/onboarding `region`, regional API endpoint helpers, org project region badges). Almost all of that is gated on **Cloud** (`isCloud` / `PUBLIC_CONSOLE_MODE=cloud`).

Self-hosted operators running a **meta** API plus **regional** APIs cannot use that UI today: no region picker, create/onboarding omits `region`, and there is no supported way to load a region catalog or map a project’s `region` to an API host without Cloud’s `organizations.listRegions` / Cloud subdomain conventions.

### 🎤 Pitch

Once the backend can run meta + regional stacks (https://github.com/appwrite/appwrite/issues/12964), the console must:

- Load a self-hosted region catalog at **runtime** (no rebuild when regions change)
- Let operators pick a region when creating projects (create modal + onboarding)
- Route SDK/API calls using an **explicit optional hostname/endpoint per region**
- Show region on org project lists

Without this, self-hosted multi-region only works via raw API and is unusable for normal console workflows.

### 👍 Solution / proposed scope

Discuss and (if accepted) implement:

1. **`isMultiRegion` (or equivalent)** — e.g. `PUBLIC_APPWRITE_MULTI_REGION=true` and/or a console variable from the API (`_APP_SUPPORTS_MULTI_REGION`), not Cloud-only.

2. **Runtime region catalog** — serve a static JSON file from the console nginx image, e.g. `GET /console/regions`, so Helm/compose can mount a ConfigMap/volume without rebuilding the SPA. Shape should mirror the API catalog idea (`$id`, `name`, availability flags) plus optional routing fields:
- `hostname` → `{page-protocol}//{hostname}/v1`
- `endpoint` → full API base (with or without `/v1`)
- Example: `{ "$id": "fra", "name": "Frankfurt", "disabled": false, "available": true, "hostname": "fra.example.com" }`
- If neither `hostname` nor `endpoint` is set, keep existing Cloud subdomain behavior as fallback (or same-origin).

3. **Create + onboarding** — when multi-region is on, show the region picker and send `region` on project create. Prefer the **self-hosted create modal**, not the Cloud wizard (Cloud path can coalesce region to `default`).

4. **Org UI** — show region name on project cards when multi-region is enabled (same presentation as Cloud).

5. **Align `getApiEndpoint` / `getProjectEndpoint` / copy-display URLs** with the catalog overrides.

We prototyped this in a Helm/nginx setup (ConfigMap-mounted `/console/regions`). Happy to adjust to whatever maintainers prefer (API-served catalog vs static file) as long as it stays runtime-configurable and host-explicit.

Depends on / coordinated with backend multi-region: https://github.com/appwrite/appwrite/issues/12964

### 👀 Have you spent some time to check if this issue has been raised before?

- [x] I checked; existing console region work targets Cloud subdomain routing / Cloud APIs, not self-hosted multi-region UX with a runtime catalog.

### 🏢 Have you read the Contributing Guidelines on issues?

- [x] I have read the Contributing Guidelines (https://github.com/appwrite/console/blob/main/CONTRIBUTING.md) (open an issue explaining the idea before a PR; discuss fit with roadmap).

Start by tracing the existing region picker, create/onboarding flows, project cards, and the getApiEndpoint/getProjectEndpoint helpers referenced in the issue. Review the proposed /console/regions runtime catalog and the backend dependency in issue #12964 before choosing an approach. Done means self-hosted multi-region operators can load changing region data, choose a region, see it in project lists, and use the configured regional endpoints.

Written by the indexing model from the issue text.