Define an explicit scale-qualified recipe configuration contract

[mchmarny]

Feature summary

Define how users explicitly select a scale-qualified AICR configuration and how that choice composes with recipes, bundles, and overrides.

Problem and use case

AICR can transport chart values, but it does not currently expose a scale-selection contract:

• --nodes is advisory and only reaches registry-declared paths.
• --set transports caller-selected values; it does not derive scale-safe values.
• --dynamic exposes selected values at deployment time; it does not compute them and is not supported by every deployer.

Using node count to silently select a specialized configuration would violate AICR's explicit-intent and reproducibility principles.

Proposed solution

Select and implement an explicit, versioned contract, such as a scale-qualified overlay/profile or versioned values set. The design must define:

• supported node ranges or qualification bands
• the component settings owned by each band
• required external prerequisites
• precedence with bases, mixins, --nodes, --set*, and --dynamic
• validation behavior when actual cluster size or prerequisites differ
• how the selected contract appears in resolved recipes, bundles, queries, and evidence

Success criteria

• Selecting scale-qualified behavior requires explicit user intent.
• Node count alone never silently specializes a recipe.
• Identical inputs resolve to byte-stable, versioned configuration.
• Every scale-owned value and prerequisite has one discoverable source of truth.
• User overrides either compose predictably or fail with a clear conflict.
• Unsupported deployer and --dynamic combinations fail before bundle output.
• The selected scale contract is queryable and recorded in qualification evidence.
• CLI, API, recipe-development, and contributor documentation are updated.

Compatibility

The design should preserve existing recipe queries and bundles unless a user explicitly opts into the scale-qualified contract.