[ai-core] Provide well-known deployment specs as reusable constants (RPT-1 + Orchestration)

[Schmarvinius]

Context

Currently, RptModelSpec lives in cds-feature-recommendations and defines how to resolve/provision an RPT-1 deployment. This creates two problems:

1. Other consumers (future orchestration features, custom extensions) cannot reuse deployment resolution without depending on the recommendations module
2. Adding new well-known deployment types (e.g., orchestration) has no natural home
   The Node.js counterpart defines both rpt1ForResourceGroup and orchestrationForResourceGroup in its AI Core service layer, making them available to any consumer.

Proposal

Move well-known deployment specifications into cds-feature-ai-core as reusable constants. Consumers (including cds-feature-recommendations) reference them from ai-core instead of owning them.

// In cds-feature-ai-core
public final class WellKnownDeployments {
    public static final ModelDeploymentSpec RPT1_SMALL = new ModelDeploymentSpec(
        "foundation-models",
        "aicore-sap",
        "sap-rpt-1-small",
        List.of(
            new AiParameterArgumentBinding().key("modelName").value("sap-rpt-1-small"),
            new AiParameterArgumentBinding().key("modelVersion").value("latest")
        ),
        deployment -> /* match on backend details model name */
    );
    public static final ModelDeploymentSpec ORCHESTRATION = new ModelDeploymentSpec(
        "orchestration",
        // ... TBD params
    );
}

Changes

cds-feature-ai-core:

• Add WellKnownDeployments class (or similar) with static constants for RPT-1 and Orchestration specs
• Keep ModelDeploymentSpec open for custom specs from consumers
  cds-feature-recommendations:
• Remove RptModelSpec
• Replace usage with WellKnownDeployments.RPT1_SMALL from ai-core

Acceptance Criteria

• WellKnownDeployments.RPT1_SMALL available in cds-feature-ai-core
• WellKnownDeployments.ORCHESTRATION available in cds-feature-ai-core
• cds-feature-recommendations consumes spec from ai-core (no longer owns it)
• Custom ModelDeploymentSpec still works for arbitrary deployments
• Existing tests pass (no behavioral change)
• Unit test verifying orchestration deployment resolution

[Schmarvinius]

Also create an interface/abstract-class/record, so consumers can introduce their own