Problem

Tools that consume AICR as a library/CLI with external --data (e.g. an internal
recipe repo that packages scenarios as OCI bundles) need to know which criteria
combinations resolve to a curated leaf overlay vs. a generic fallback, so they can
build a bundle catalog automatically instead of hand-maintaining one.

Today there is no way to enumerate the catalog. The only workarounds are both fragile:

1. Discovering valid enum values — the accelerator/service lists only appear as
   e.g. hint text in aicr recipe --help (Accelerator/GPU type (e.g. a100, b200, gb200, h100, h200, l40, rtx-pro-6000)). That's not a guaranteed-complete machine API,
   so a new accelerator (e.g. a future l40s) may not be discoverable programmatically.
2. Distinguishing curated from fallback — we must probe every
   service × accelerator × intent × os combination, run aicr recipe, and inspect
   metadata.appliedOverlays to check whether a dedicated <accel>-<service> leaf was
   applied (curated) or only <accel>-any + a generic <service>-training overlay
   (fallback). aicr recipe resolves anything via fallback, so "it resolves" is not a
   usable filter.

Request

Add a read-only aicr recipe list (or aicr catalog) subcommand that enumerates the
curated overlays and emits JSON (machine-readable, --format json|yaml, default
text table). Each entry should carry at least:

• the overlay metadata.name (the leaf)
• its criteria (service, accelerator, os, intent, platform)
• whether it is a curated leaf vs. a generic/base overlay
• (nice to have) the source: embedded (OSS) vs. external --data

It should honor --data (so external overlays are included with correct precedence) and
accept optional filter flags — --service, --accelerator, --intent, --os — that
narrow the same output. Per-cloud filtering is just a view over the full catalog, so
supporting both the full dump (default) and filters costs little extra and covers every
caller.

Example

$ aicr recipe list --format json --service eks --intent training
[
  {"name":"gb200-eks-ubuntu-training","criteria":{"service":"eks","accelerator":"gb200","os":"ubuntu","intent":"training"},"curated":true,"source":"embedded"},
  {"name":"h100-eks-ubuntu-training","criteria":{"service":"eks","accelerator":"h100","os":"ubuntu","intent":"training"},"curated":true,"source":"embedded"}
]

Why

This unlocks zero-touch catalog discovery for downstream users: when AICR adds a new
accelerator or curated overlay, downstream users bump their pinned aicr and the new
scenarios are picked up automatically — no hand-maintained matrix, no e.g.-help-text
parsing, no per-combo probing.