fix: fix response class strictness

[OscarDDD]

Context

Closes SAP/ai-sdk-python-backlog#22.

What this PR does and why it is needed

The orchestration service v2 spec
defines a reasoning_content field on AssistantChatMessage, ResponseChatMessage, and ChatDelta.
The Python SDK did not declare this field, and the response-related classes (ResponseChatMessage,
StreamDelta, etc.) inherited from ABCBaseModel (extra="forbid"), causing a Pydantic
ValidationError whenever the orchestration service returned reasoning_content — which happens by
default for models such as gemini-3.5-flash (see #92).

This PR explicitly adds reasoning_content: Optional[List[ReasoningBlock]] to AssistantMessage and
StreamDelta, and fixes the root cause by making all response-related classes inherit from
ResponseBaseModel (extra="allow") so that any currently-unknown field returned by the server is
accepted rather than rejected. This covers FunctionCall, MessageToolCall, ReasoningBlock,
ResponseChatMessage in message.py; all classes in response.py; and EmbeddingsUsage,
EmbeddingResult, EmbeddingsResponse, EmbeddingsPostResponse in embeddings.py.
ResponseBaseModel is moved from response.py into base.py to avoid a circular import.

Scope

All changes are confined to packages/gen/gen_ai_hub/orchestration_v2/. Other packages
(document_grounding, proxy, prompt_registry, batch_service) may have the same pattern
and should be discussed later. Some models are shared through requests and responses. They are now updated to use ResponseBaseModel.

Definition of Done

• Code is tested (Unit, Integration, E2E)
• Error handling created / updated & covered by the tests above
• Documentation updated
• (Optional) Aligned changes with the JS/TS and Java SDK
• (Optional) Release notes updated

[hyperspace-pr-bot]

👋 Hi — I'm PR Bot, your SAP code review assistant.

I'll automatically review your pull requests for code quality, security, and SAP compliance. Get an overview of what I do →

What I do

• Summarize your pull request changes
• Review code for quality, correctness, and reliability
• Suggest fixes when a pipeline job fails

Key commands

Command	Description
/review [--all]	Trigger a code review. Add --all to include files excluded by excluded_paths.
/summarize	Generate a PR summary
/ask <question>	Ask about the current changes
/help	See all available commands

Configure me for your team

Create .hyperspace/pull_request_bot.json in your repository:

{
  "$schema": "https://devops-insights-pr-bot.cfapps.eu10-004.hana.ondemand.com/schema/pull_request_bot.json",
  "features": {
    "control_panel": false,
    "summarize": {
      "auto_generate_summary": true,
      "auto_insert_summary": true,
      "auto_run_on_draft_pr": true,
      "use_custom_summarize_prompt": false,
      "use_custom_summarize_output_template": false,
      "excluded_paths": [],
      "auto_exclude_authors": []
    },
    "review": {
      "auto_generate_review": true,
      "auto_run_on_draft_pr": false,
      "use_custom_review_focus": false,
      "excluded_paths": [],
      "auto_exclude_authors": []
    },
    "sonar_fix": {
      "enable": true,
      "excluded_rules": []
    },
    "pipeline_fix": {
      "enable": true
    }
  },
  "excluded_paths": []
}

Full configuration reference →

*This introduction message will be shown to you only once, you will not see it in future PRs.

[yamaceay]

[pp] Would it be more convenient for review to set the base branch to #92 or what do you think?

[OscarDDD]

[pp] Would it be more convenient for review to set the base branch to #92 or what do you think?

yeah, I have the same idea. This branch is currently created from the #92, the commit 9204c29.

[yamaceay]

[pp] Would it be more convenient for review to set the base branch to #92 or what do you think?

yeah, I have the same idea. This branch is currently created from the #92, the commit 9204c29.

yes that's correct, I rather meant the GitHub PR base branch so that it reads out as "merge into orchestration-reasoning-content from fix-response-class-strictness". but again, personal preference and not important

[OscarDDD]

[pp] Would it be more convenient for review to set the base branch to #92 or what do you think?

yeah, I have the same idea. This branch is currently created from the #92, the commit 9204c29.

yes that's correct, I rather meant the GitHub PR base branch so that it reads out as "merge into orchestration-reasoning-content from fix-response-class-strictness". but again, personal preference and not important

yeah, that's better I think. I'll do it.

[yamaceay]

nice work! just adding some comments :)

[yamaceay]

Suggested change

	class AssistantMessage(ResponseBaseModel):
	class AssistantMessage(BaseModel):

[OscarDDD]

Here are some investigation from my side. They do have the same fields, but they serve different roles in the flow. ResponseChatMessage is what you get back from the model (LLMChoice.message), while AssistantMessage some other messages, like what you put into the conversation history to send back in the next turn. (Also for the type declarations mentioned)

The existing integration test makes this explicit — it reads from a ResponseChatMessage and manually constructs an AssistantMessage to append to history:

# response.final_result.choices[0].message is ResponseChatMessage — the model's output
assistant_message = AssistantMessage(
    content=response.final_result.choices[0].message.content,
    refusal=response.final_result.choices[0].message.refusal,
    tool_calls=response.final_result.choices[0].message.tool_calls,
)
history.append(assistant_message)  # AssistantMessage — going back in as input