Goal

Every accelerator declared in pkg/recipe/criteria.go must resolve at least one concrete service-bound overlay so aicr recipe --accelerator <x> --service <y> ... produces a usable recipe for the dominant deployment shapes (training and inference on the major hyperscalers).

Parent initiative: #1041.

Success criteria

For every declared accelerator (CriteriaAccelerator* in pkg/recipe/criteria.go):

1. recipes/overlays/ contains at least one concrete service-bound overlay (non-wildcard) for the accelerator's primary deployment intent.
2. aicr recipe --accelerator <x> --service <y> --intent <z> resolves a recipe end-to-end without manual overlay authoring.
3. The overlay is referenced by — or covered as an exemption in — recipes/overlays_validation_floor_test.go.

Scope

In scope:

• New service-bound overlays for declared accelerators that have zero coverage today.
• Promotion of wildcard stubs (<accel>-any-*.yaml) to concrete service-bound leaves.
• Audit-style follow-ups when a new accelerator is added to pkg/recipe/criteria.go without corresponding overlays.

Out of scope (other epics under #1041):

• Performance-phase constraints on the new overlays — those land via the performance Epic.
• Validator behavior on workload variants — that's the validator capability Epic.

New coverage gaps should be filed as standalone issues and attached here as sub-issues.