chore: forward requestconfig to deployment api calls

[davidkna-sap]

Context

Part of SAP/ai-sdk-js-backlog#621.

What this PR does and why it is needed

[hyperspace-pr-bot]

Summary

The following content is AI-generated and provides a summary of the pull request:

---

What this PR does and why it is needed

This PR forwards the requestConfig parameter to deployment API calls when resolving deployment IDs. Previously, the requestConfig provided by callers was used only for the main inference request but was ignored during the deployment resolution step (fetching the deployment ID from the AI Core service).

Changes

• deployment-resolver.ts: Added requestConfig?: CustomRequestConfig to the DeploymentResolutionOptions interface and updated getAllDeployments, getFoundationModelDeploymentId, and getOrchestrationDeploymentId to accept and forward the requestConfig to the underlying DeploymentApi.deploymentQuery().execute() call.

• azure-openai-chat-client.ts & azure-openai-embedding-client.ts: Pass requestConfig to getFoundationModelDeploymentId so custom request configuration is applied during deployment resolution.

• orchestration-client.ts & orchestration-embedding-client.ts: Pass requestConfig to getOrchestrationDeploymentId for the same reason.

Category: 🔧 Chore

---

• 🔄 Regenerate and Update Summary
• ✏️ Insert as PR Description (deletes this comment)
• 🗑️ Delete comment

PR Bot Information

Version: 1.29.2

• Correlation ID: 03c58f40-8684-11f1-873d-ebf1decc7f99
• Summary Prompt: Default Prompt
• LLM: anthropic--claude-4.6-sonnet
• Output Template: Repository PR Template
• Event Trigger: pull_request.opened
• File Content Strategy: Full file content

[marikaner]

[pp] I don't like it when functions have more than 3 parameters, especially when the last two are optional. Given, that this is an internal function, I would prefer it, if we combined destination and requestConfig into one parameter. Maybe even adding modelDeployment.
What do you think about that?