Chore: Move env config into each app

- Drop the root .env.* files; every app now has its own .env.example
- Core console talks to core directly with its build-time key
- ALLOWED_HOST passed through docker-compose

.env.development

@@ -1,3 +0,0 @@
-# Development environment variables
-# Change this to your local API URL if needed (e.g., http://localhost:3001/api)
-VITE_API_BASE_URL=https://api-dev.xcloudify.tech/api

.env.example

@@ -1,7 +0,0 @@
-PORT=8080
-API_TARGET=http://127.0.0.1:5000
-ALLOWED_HOST=127.0.0.1
-VITE_API_BASE_URL=http://127.0.0.1:5000/api
-VITE_WS_BASE_URL=http://127.0.0.1:6001
-VITE_WS_PATH=/ws
-VITE_XCLOUDIFY_API_KEY=

.env.production

@@ -1,2 +0,0 @@
-# Production environment variables
-VITE_API_BASE_URL=https://api.xcloudify.tech/api

apps/cloud/docker-compose.yml

@@ -4,10 +4,11 @@ services:
     build:
       context: ../..
       dockerfile: Dockerfile
-    container_name: xcloudify-portal
+    container_name: xcloudify-cloud-portal
     environment:
       APP: cloud
       PORT: "8080"
+      ALLOWED_HOST: ${ALLOWED_HOST:-localhost}
       VITE_API_BASE_URL: ${VITE_API_BASE_URL:-http://localhost:5001/api}
       VITE_WS_BASE_URL: ${VITE_WS_BASE_URL:-http://localhost:6001}
     ports:

apps/core/.env.example

@@ -9,3 +9,5 @@
 # its hardcoded defaults, which point at the cloud plane.
 VITE_API_BASE_URL=http://localhost:5000/api
 VITE_XCLOUDIFY_API_KEY=change-me-generate-a-real-key
+
+ALLOWED_HOST=localhost

apps/core/docker-compose.yml

@@ -10,6 +10,7 @@ services:
     environment:
       APP: core
       PORT: "8083"
+      ALLOWED_HOST: ${ALLOWED_HOST:-localhost}
       VITE_API_BASE_URL: ${VITE_API_BASE_URL:-http://localhost:5000/api}
       VITE_XCLOUDIFY_API_KEY: ${VITE_XCLOUDIFY_API_KEY:?set this to core's XCLOUDIFY_API_KEY (theapi/core/.env on the box behind the tunnel) so the console can authenticate}
     ports:

apps/core/src/App.tsx

@@ -2,19 +2,16 @@
  * Operator console for the core underlay: hosts, workloads, networks,
  * storage, regions, images, capacity.
  *
- * Core itself is identity-free and holds no user accounts, so normally this
- * app never talks to core directly -- it points at whichever identity plane
- * is deployed (cloud or community) and uses that plane's /api/admin/core/*
- * gateway. Both planes serve that surface identically from the shared
- * allowlist, which is what lets one console work against either. Set
- * VITE_API_BASE_URL to the plane in front of it.
+ * Talks to core directly, always: this app is built with
+ * VITE_XCLOUDIFY_API_KEY set and VITE_API_BASE_URL pointing at core's own
+ * /api root, and attaches that key to every call (see xcloudifyApi.ts).
+ * There is no route through cloud -- cloud's backend is the only *server*
+ * that calls core on a user's behalf, and it holds its own key; no browser
+ * ever borrows it.
  *
- * Exception: a bare `--core` deploy (deploy-dev.sh, no plane at all) instead
- * builds this app with VITE_XCLOUDIFY_API_KEY set, which points it straight
- * at core with the service key attached (see xcloudifyApi.ts). Deliberate,
- * non-internet-facing-demo-only tradeoff -- that key is unrestricted admin
- * over every tenant with no scoping, so this must never be set for a build
- * that could reach a real user.
+ * That key is unrestricted admin over every tenant with no scoping, so this
+ * console is an operator tool for a trusted network. It must never be served
+ * somewhere a tenant user could load it.
  *
  * There is no tenant-facing half and no tenancy administration: universes,
  * projects, VDCs, certificates and billing are cloud's, and core has no