Move Odin renderer into gui/ with per-project Makefiles

Each sub-project (gui, api, infra) now owns its own Makefile, and the
root Makefile is a lean delegator for the base commands (run, build,
test, clean, fmt). Odin source, deps, and web assets live under gui/
(gui/src, gui/lib, gui/www), with scripts kept under gui/scripts for
build tooling only.

README.md

@@ -42,17 +42,20 @@ Early scaffolding. The application currently:
 ## Repository Layout
 
 ```
-src/       Odin source — the interactive 3D experience (entrypoint: src/main.odin)
-lib/       Third-party Odin dependencies (submodules / vendored libs)
-api/       Rust backend API (axum) for serving DESI catalog data
-infra/     Go + Pulumi infrastructure-as-code (deploys the experience to k8s)
-scripts/   Build helpers (Odin install, WASM build)
-.gitea/    Gitea Actions CI/CD workflows
+gui/           Odin renderer — the interactive 3D experience (entrypoint: gui/src/main.odin)
+  gui/lib/     Third-party Odin dependencies (submodules / vendored libs)
+  gui/www/     Web GUI — WASM shell / static web assets
+  gui/scripts/ Build scripts (WASM build helper)
+api/           Rust backend API (axum) for serving DESI catalog data
+infra/         Go + Pulumi infrastructure-as-code (deploys the experience to k8s)
+scripts/       Repo-level build helpers (Odin install)
+.gitea/        Gitea Actions CI/CD workflows
 ```
 
-The renderer (`src/`), the API (`api/`), and the infrastructure (`infra/`) are
-kept in separate directories so their logic stays cleanly separated; all are
-orchestrated by the root `Makefile`.
+The renderer (`gui/`), the API (`api/`), and the infrastructure (`infra/`) are
+kept in separate directories so their logic stays cleanly separated. Each
+project carries its own `Makefile`; the root `Makefile` delegates the base
+commands (`run`, `build`, `test`, ...) into them.
 
 ## Building & Running
 
@@ -62,21 +65,33 @@ vendor bindings. The web build additionally requires [Emscripten](https://emscri
 pinned via `api/rust-toolchain.toml`). The infrastructure requires
 [Go](https://go.dev) and [Pulumi](https://www.pulumi.com).
 
-All project commands live in the root `Makefile` (`make help` lists them):
+The root `Makefile` delegates everything to the per-project Makefiles
+(`make help` lists the base targets):
 
 ```sh
 make setup        # pull submodules + tidy Go deps
-make run          # run the native app
-make build        # -> bin/desi_explorer
-make build-debug  # debug native build
-make build-web    # -> build/web (wasm + html)
+make run          # run the native app (gui/)
+make build        # -> bin/desi_explorer (gui/)
+make build-debug  # debug native build (gui/)
+make build-web    # -> build/web (wasm + html, gui/)
 make test         # odin test + go test + cargo test
-make clean        # remove build artifacts
-make api-run      # run the Rust API server
-make api-test     # cargo test
-make api-check    # rustfmt check + clippy
+make clean        # remove build artifacts from all projects
+make fmt          # format all projects
 ```
 
+Project-specific targets live in their own `Makefile` and are reached with
+`make -C <dir> <target>`:
+
+```sh
+make -C gui help    # Odin renderer (run, build, build-debug, build-web, test, fmt)
+make -C api help    # Rust API (run, build, test, check, fmt)
+make -C infra help  # Infra (preview, up, down, refresh, static, test)
+```
+
+The root also provides thin passthroughs: `make api-<target>` and
+`make infra-<target>` forward to the corresponding sub-project (e.g.
+`make api-check` -> `make -C api check`).
+
 ## Dependency Updates (Renovate)
 
 [Renovate](https://github.com/renovatebot/renovate) keeps dependencies up to
@@ -91,5 +106,5 @@ It manages four categories:
 
 - **Infra dependencies** — `infra/go.mod` (`gomod` manager); minor/patch updates grouped into a single PR.
 - **API dependencies** — `api/Cargo.toml` (`cargo` manager); minor/patch updates grouped into a single PR.
-- **Submodules** — `lib/` submodules via `.gitmodules` (`git-submodules` manager).
+- **Submodules** — `gui/lib/` submodules via `.gitmodules` (`git-submodules` manager).
 - **Workflow actions** — action versions in `.gitea/workflows/*.yml` (`github-actions` manager, which understands Gitea's `.gitea` layout).