updated http library to return error and response structs; updated how the GUI works to have a 'wait' UI; updated Makefile to ensure API is started before starting GUI

README.md

@@ -25,6 +25,7 @@ A fun personal project with three interlocking goals:
 Early scaffolding. The application currently:
 
 - Opens a resizable 3D raylib window with an orbital camera (zoom + rotate + pan).
+- Starts on a launch screen where you configure the API URL, pick a region, hit **Refresh catalogs** to pull the catalog list, and press **Explore** to enter the 3D view (TAB returns to the launch screen).
 - Renders a procedurally generated point cloud standing in for the galaxy catalog (real DESI data ingestion is the next milestone).
 - Compiles natively, to WebAssembly, and is deployed to an on-prem Kubernetes cluster as a placeholder web service.
 
@@ -95,6 +96,14 @@ The defaults point at `resources/dev/gui.env.example` (renderer's `API_URL`),
 `resources/dev/desi_subset.json` (a small JSON catalog subset served by the
 API's `/api/v1/catalogs` and `/api/v1/objects` endpoints).
 
+`make run` and `make run-web` start the API in the background and then wait for
+its `/health` endpoint before launching the GUI (`make api-wait`), so the
+renderer never races the API on startup. Override the bind address and worst
+case wait with `API_BIND_ADDR` (default `127.0.0.1:8080`) and
+`API_WAIT_TIMEOUT` (default 60s). The earlier you click **Refresh** on the GUI's
+launch screen, the more likely you are to catch the API mid-boot; a slow API can
+also be re-polled by pressing **Refresh** again.
+
 Project-specific targets live in their own `Makefile` and are reached with
 `make -C <dir> <target>`: