[bug]: prime-cli v2.2.0 panics on fresh install — downloaded variables.env is 0 bytes

Summary

prime-cli v2.2.0 panics during a fresh Commercial Edition install. The variables.env asset it downloads is 0 bytes, and SortEnvMap then indexes past the end of the slice.

Environment

• Fresh Ubuntu 24.04.4 VM, 4 vCPU / 8 GB / 80 GB
• Docker 29.7.2, Docker Compose v5.4.0 (installed beforehand, via get.docker.com)
• prime-cli v2.2.0 (build 8e0522a) — prime-cli update-cli reports it is already up to date
• /opt/plane/.config.env reports VERSION=v3.1.0, PLANE_ARCH=x86_64, PLATFORM=linux/amd64

Steps to reproduce

curl -fsSL https://prime.plane.so/install/ -o i.sh
sudo sh i.sh --silent --domain=<your-domain>

Reproduced three times:

1. --silent, first run
2. --silent, after rm -rf /opt/plane (completely clean state)
3. interactive TUI (Express, "behind a reverse proxy: Yes")

All three crash identically, at the Downloading latest file assets stage.

Actual behaviour

panic: runtime error: index out of range [275] with length 275

goroutine 1889 [running]:
github.com/makeplane/prime-cli/internal/utils.SortEnvMap(...)
        internal/utils/file_utils.go:180
github.com/makeplane/prime-cli/internal/environment.compareAndUpdateEnvFiles({...}, 0x1)
        internal/environment/main.go:82 +0xffd
github.com/makeplane/prime-cli/internal/environment.(*Environment).InstallAssets(...)
        internal/environment/main.go:280 +0xd6
github.com/makeplane/prime-cli/internal/tui.DownloadFileAssets.func1()
        internal/tui/app_stages.go:405 +0x2f2

(The silent path shows the same panic with compareAndUpdateEnvFiles({...}, 0x0).)

Contents of /opt/plane after the crash:

-rw-r--r-- 1 root root   281  .config.env
-rw-r--r-- 1 root root  1379  Caddyfile
-rw-r--r-- 1 root root 23558  docker-compose-caddy.yml
-rw-r--r-- 1 root root 23558  docker-compose-nginx.yml
-rw-r--r-- 1 root root 23558  docker-compose.yml
-rw-r--r-- 1 root root     0  variables.env      <-- empty

Every other asset downloads intact, which suggests the variables.env asset itself is served empty rather than a network problem on our side.

Expected behaviour

variables.env is populated and the installation completes.

Suggestions

1. Serve a non-empty variables.env asset for v3.1.0.
2. Make SortEnvMap / compareAndUpdateEnvFiles fail with a clear message ("downloaded variables.env is empty") instead of panicking. As it stands, the stack trace points at env-file comparison, which sends you looking for leftover state from a previous install — the actual cause is an empty download.

Note

An earlier, unrelated failure in the same session: the installer's own Docker installation step failed with /tmp/i.sh: 77: [: Linux: unexpected operator (a sh vs bash string-comparison issue) and reported Failed to Install Docker, please try installing manually. Installing Docker beforehand worked around that one.

Start with internal/utils/file_utils.go:180 and the callers in internal/environment/main.go:82 and :280 to trace how an empty variables.env reaches SortEnvMap. Check the v3.1.0 asset and the download stage, then reproduce the fresh install. Done means the asset is non-empty and failures report a clear error instead of panicking.