mw app create --set im=<version> fails with 404 resolving system-software versions #1974

Summary

mw app create <runtime> --set im=<version> (ImageMagick) fails at the version-resolution step with a 404, so ImageMagick can't be added to a runtime app via --set. The same versions endpoint returns 200 when called directly, and creating the app with ImageMagick via the raw API works — so this is a CLI-side resolution bug.

Verified against mw 1.19.0.

Repro

mw app create php -p <project> --install-path foo --document-root / --set im=~7.1 -w

Step 1: fetching system softwares... completed
Step 2: fetching versions for im... FAILED
  Error: AxiosError: Request failed with status code 404
  Request  GET v2/system-softwares/e015b8f3-c0bd-43c3-a8bf-2865028bbb50/versions
  Response 404 Not Found  ("no system software versions found")

Why this looks CLI-side

• The same endpoint returns 200 with a full list when called directly:
  GET /v2/system-softwares/e015b8f3-.../versions → 6.9.4-6 … 7.1.2-15.
• --set node=~22 gets past this step (Step 2 completes) — so it isn't --set in general; it's specific to (at least) im.
• Installing ImageMagick via the raw API works:
  POST /v2/projects/{id}/app-installations with
  "systemSoftware": { "e015b8f3-…": { "systemSoftwareVersion": "<versionId>", "updatePolicy": "patchLevel" } }
  → 201, and convert (ImageMagick 7.1.2-15) is present in the app afterwards.

So ImageMagick is installable; only the CLI --set version resolution for im 404s.

Minor, likely separate (API robustness)

In that POST body, passing a version range/string (e.g. ~7.1) as systemSoftwareVersion returns 500 Internal Error instead of a 400 — the field expects the version UUID. A clear 400 (or accepting a range) would help hand-rollers.

Context

Surfaced while validating the mittwald-migrate skill. Installing image/PDF tooling (im, gm, libvips, …) as system software is the recommended alternative to a container; the --set bug currently blocks the CLI path for ImageMagick.