fix: stream Azure Responses function-call arguments

[FrigaZzz]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Related: Feature: Stream partial function-call arguments across model adapters #6630

Problem:

When an Azure OpenAI Responses request used stream=True, ADK accumulated
function-call argument deltas internally but did not expose them to streaming
consumers. Applications could display token-by-token text but appeared idle
while Azure generated a large or complex tool invocation.

Solution:

Expose Azure/OpenAI Responses function-call argument events through ADK's
existing streaming contract:

• Emit LlmResponse(partial=True) when a function call starts and as argument
  fragments arrive.
• Put raw argument fragments in FunctionCall.partial_args and set
  FunctionCall.will_continue=True.
• Preserve a stable function-call ID across partial and final events.
• Continue emitting the existing final non-partial FunctionCall with parsed
  args after generation completes.
• Fall back to the response.function_call_arguments.done or completed output
  item when Azure does not provide separate delta events.
• Reject malformed, incomplete, unnamed, or non-object final function calls so
  incomplete arguments cannot become an executable empty tool call.

No new public option or feature flag is introduced. Function-call arguments
are streamed whenever the caller already opts into streaming with
stream=True; non-streaming behavior remains unchanged.

This PR intentionally limits the implementation to OpenAI Responses and Azure
OpenAI Responses. The other adapters discussed in #6630 are outside this PR's
scope.

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

The focused OpenAI Responses unit tests pass locally. Coverage includes:

• Incremental response.function_call_arguments.delta events.
• Stable IDs across partial and final function-call events.
• Final argument aggregation and JSON parsing.
• Arguments supplied only by response.function_call_arguments.done.
• Streams that finish without a response.completed event.
• Interleaved text, reasoning, and function-call events.
• Failed and incomplete stream termination.
• Malformed or non-object final function-call arguments.

Focused test command:

pytest -q tests/unittests/labs/openai/test_openai_responses_llm.py

Manual End-to-End (E2E) Tests:

Tested with an Azure / Native OpenAI Responses deployment using both the ADK Dev UI and
the included terminal runner.

Setup:

export AZURE_API_KEY="<azure-api-key>"
export AZURE_RESOURCE_NAME="<azure-resource-name>"
export AZURE_MODEL_DEPLOYMENT="<azure-model-deployment>"

Dev UI:

uv run --extra extensions adk web \
  contributing/samples/models/azure_responses_streaming

Terminal runner:

uv run --extra extensions python \
  contributing/samples/models/azure_responses_streaming/run.py

Observed behavior:

1. The stream emits multiple partial function-call events containing raw
   argument fragments before tool execution.
2. Every partial event uses the same function-call ID and has
   will_continue=True.
3. Partial events do not trigger tool execution.
4. The final non-partial event contains the fully parsed function arguments.
5. The create_document tool executes only after the final function call and
   writes the requested Markdown document.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules. (N/A: no dependent changes.)

Additional context

The sample intentionally uses a large nested Pydantic tool schema so Azure
emits enough function-call argument fragments to make progressive streaming
easy to observe in the Dev UI and terminal output.

Partial argument fragments are informational only. Tool execution continues to
use the final validated and parsed FunctionCall.args.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.