Summary

When aicr recipe is called for a service whose overlays all require an explicit OS (OKE or GKE), omitting --os silently returns a base-only recipe with exit 0 instead of failing with a clear error. The user receives a recipe missing all service-specific settings (GPU Operator config, constraints, conformance checks, etc.) with no indication that anything is wrong.

Reproduction

# OKE — exits 0, returns 3-overlay base-only recipe (missing all oke-ol / l40s-oke settings)
aicr recipe --service oke --accelerator l40s --intent training

# GKE — same behavior, exits 0 with base-only recipe
aicr recipe --service gke --accelerator h100 --intent training

Root Cause

pkg/recipe/metadata_store.go:909 — when FindMatchingOverlays returns no environment-specific overlays (because the query os="" doesn't match any overlay with an explicit os: criterion), the resolver logs slog.Warn("no environment-specific overlays matched, using base configuration only") and returns the base recipe with exit 0.

Impact

• Silent misconfiguration: user deploys a recipe that lacks OKE/GKE-specific GPU Operator values, constraints, DRA config, cert-manager settings, etc.
• No error is surfaced to the CLI caller or the API consumer.
• Confirmed for OKE (os: ol overlays) and GKE (os: cos overlays).

Proposed Fix

Add a fail-closed guard in BuildRecipeResult / BuildRecipeResultWithEvaluator: if the query specifies a service that has at least one overlay (i.e., the service is known), but zero service-specific overlays match (the service overlays all require an OS the query didn't supply), return ErrCodeNotFound with a hint listing the available OS values for that service.

This makes omitting --os for OKE/GKE an explicit, actionable error:

Error: service 'oke' requires an explicit --os (available: ol, ubuntu)