feat(cloud): validate devices and OS versions against live API data

[finalerock44]

What & why

dcd cloud validated --ios-device, --ios-version, --android-device and --android-api-level with validateEnum against the CLI's hard-coded enums before the API was consulted. Any value missing from the enum was refused, even when the API runs it: the live 5.5.0 refuses iphone-17, iphone-air, iphone-18-pro(-max) and ipad-pro-m5-11/-13, and #187 only fixed that for the devices known today.

These values are now checked only against the compatibility data the API returns (GET /results/compatibility/data). DeviceValidationService already checked the device/version pair against that data. The enums are kept for --help only, so new devices and OS versions no longer need a CLI release. An unknown device still fails before anything is uploaded, and the error now lists what the API offers:

$ dcd cloud app.zip flow.yaml --ios-device iphone-99
✗ Error: iOS device "iphone-99" is not supported. Supported iOS devices: iphone-14, iphone-15, iphone-16, …, ipad-pro-m5-13. See https://docs.devicecloud.dev/getting-started/devices-configuration
$ dcd cloud app.apk flow.yaml --android-device pixel-8 --google-play
✗ Error: Android device "pixel-8" is not available with Google Play. Google Play devices: pixel-7. See …
$ dcd cloud app.zip flow.yaml --ios-device iphone-17 --ios-version 26 --dry-run
⚠ Dry run mode — no tests were actually triggered

(Output from the built CLI against the mock API.)

Lone device or lone version (API follow-up)

If a request names only a device, or only a version, the other half is still checked against the API's global defaults: iOS 17 / API 34 for the version, iphone-14 / pixel-7 for the device. The API does the same thing. In test-request-validator.service.ts, on both dcd production (f53533fd) and dev (efb9face), the body destructures iOSVersion = '17' and androidApiLevel = '34' and returns a 400 for an incompatible pair. It never picks a version that suits the device.

So --ios-device iphone-17 or --android-device pixel-10 on its own fails in both places. The CLI error now says which default was checked and which flag to pass:

✗ Error: iphone-17 only supports these iOS versions: 26, 27. No iOS version was given, so the default (17) was checked: pass one of those explicitly with --ios-version
✗ Error: iphone-14 only supports these iOS versions: 17, 18. No iOS device was given, so the default (iphone-14) was checked: pass one that offers iOS 27 with --ios-device: iphone-16, …

Follow-up for the API (not changed here): the API could resolve a version that suits the device, or publish its defaults in the compatibility payload. The CLI's copy of the defaults (device-validation.service.ts) has to change whenever the API's do, for example with the announced 19 Oct (API 36) and 26 Oct (pixel-10) default changes. One exception is already handled: if the API stops offering the device the CLI assumes is the default, a version-only request goes through to the API rather than being refused on a stale assumption.

Matrix, per-flow, MCP

• --ios-device-matrix / --android-device-matrix cells were already validated one by one through this service, never the enums. They get the new messages.
• Per-flow DEVICECLOUD_OVERRIDE_* devices are validated by the API, whose execution planner returns errors that name the flow. The CLI never checked them against the enums, so nothing changes there.
• dcd_run_cloud_test (MCP) uses the same service. Its hints name its own parameters (iosVersion, androidDevice, …), not CLI flags.

Type of change

• fix — bug fix
• feat — new feature
• perf — performance improvement
• refactor — code change that's neither a fix nor a feature
• docs — documentation only
• chore / ci / build / test — tooling, no user-facing change
• Breaking change (title has ! or PR notes a breaking-change footer)

Checklist

• PR title follows the Conventional Commits format (see comment above)
• pnpm lint passes (0 errors; the 32 existing warnings are unchanged)
• pnpm typecheck passes
• pnpm build passes
• I have not bumped the version or edited CHANGELOG.md (release-please handles this)
• I have signed the CLA (the bot will prompt on first contribution)
• Docs / README.md / STYLE_GUIDE.md updated if behaviour or output changed

How to test

• pnpm lint && pnpm typecheck && pnpm test. The integration suite ran locally against a Prism mock of dcd-dev's swagger.json (efb9face, #1425), and this change touches the API surface. Result: 249 passing (228 before, plus 19 unit and 2 integration tests).
• test/unit/device-validation.service.test.ts uses a payload with devices the enum doesn't have (iphone-19, pixel-12). It covers unknown and gated devices, the Play-specific message, default-version and default-device hints, MCP parameter names, and a prototype-key slug.
• Manually: dcd cloud <app.zip> <flow.yaml> --ios-device iphone-17 --ios-version 26 --dry-run is accepted.

🤖 Generated with Claude Code

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.