Fix: preserve EventActions when a long-running tool returns no response

[AmaadMartin]

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):

2. Or, if no issue exists, describe the change:
   Problem: When a long-running tool returns no response, every EventActions mutation it recorded on its ToolContext is silently discarded.

In handleFunctionCallList the per-call loop short-circuits on tool.isLongRunning && !functionResponse before the function-response event is built, and that createEvent(...) is the only place actions: toolContext.actions is ever attached. So a tool that calls toolContext.state.set(...), saveArtifact(...), requestCredential(...), requestConfirmation(...), or sets skipSummarization / escalate / transferToAgent and then returns nothing loses all of it:

• Nothing is persisted — session state is only applied from event.actions.stateDelta when an event is appended.
• If every call in the batch is such a tool, no event is produced at all, so LlmAgent.postprocess returns early and no auth or confirmation request ever reaches the client.
• In a mixed batch the merged event only folds in actions from events that were pushed, so the silent tool's actions are still lost.

Solution: Emit a content-less (actions-only) event carrying just those actions, matching the Python SDK's intended behavior and the content-less event shape ADK JS already supports (getContents skips events without content.role).

• isDefaultEventActions (core/src/events/event_actions.ts) reports whether an EventActions is still entirely at its defaults. An explicitly set falsy scalar such as escalate: false counts as non-default; that keeps the predicate an honest object-vs-default comparison and is harmless, since the resulting event has no content and changes no loop or escalation behavior. It is kept module-internal — no public export until a caller outside the package needs it.
• handleFunctionCallList contributes a content-less event with the tool's actions when they are non-default, and still contributes nothing (returning null for a lone call) when they are not, so the existing "no event for a pending long-running call" contract is preserved.
• generateAuthEvent and generateRequestConfirmationEvent now read content?.role ?? 'user' instead of content!.role. Those are the two functions postprocess calls on the returned event, i.e. exactly the auth / confirmation paths this fix unblocks, and they would otherwise throw a TypeError on a content-less event. 'user' is the role every function-response event these consume is already built with. No new validation or throw sites were added.
• LlmAgent's isEmptyMetadataEvent check is narrowed with isDefaultEventActions(lastEvent.actions). The actions-only event matches the shape of the trailing empty streaming STOP chunk that clause exists for (agent-authored, not partial, no content parts, in a step that had tool calls), so without this the loop would suppress the break and issue an extra model turn while the long-running call is still pending. A trailing empty STOP chunk carries default actions, so the streaming behavior the clause was added for is unchanged. Setting endInvocation in postprocess was rejected as an alternative because it would kill the transferToAgent follow-up that this fix makes reachable for long-running tools.

mergeParallelFunctionResponseEvents needed no change — it already guards on event.content && event.content.parts and merges every event's actions — so that tolerance is pinned by test rather than by edit.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required for all PRs that are not small documentation or typo fixes.
Unit Tests:
[x] I have added or updated unit tests for my change.
[x] All unit tests pass locally.

core/test/events/event_actions_test.ts covers isDefaultEventActions for default actions and for every non-default field, including the explicitly-false scalar case.

core/test/agents/functions_test.ts covers: a silent long-running tool that touches nothing still yields null; one that records a stateDelta, skipSummarization, transferToAgent or a tool confirmation yields a content-less event carrying it; a mixed batch merges the silent tool's actions into an event whose content holds only the responding tool's part; a long-running tool that does respond and a non-long-running tool returning undefined both behave exactly as before; and both event generators produce role: 'user' from a content-less event.

core/test/agents/llm_agent_test.ts drives the agent with a turn-counting stub model and asserts the step loop stops after the actions-only event (model called exactly once, no second-turn text), and that a trailing empty chunk with default actions still lets the loop continue.

core/test/agents/long_running_tool_actions_integration_test.ts runs the whole path through InMemoryRunner: the state delta of a silent long-running tool is persisted to the session, and its requestCredential call surfaces an adk_request_credential function call to the client — neither of which happened before.

Commands run locally on the pushed commit:

npx vitest run --project unit:core core/test/agents/functions_test.ts core/test/events/event_actions_test.ts core/test/agents/llm_agent_test.ts core/test/agents/long_running_tool_actions_integration_test.ts core/test/agents/processors core/test/auth
npm run build
npm run lint
npm run format:check
npm run docs:check

Manual End-to-End (E2E) Tests:
Please provide instructions on how to manually test your changes, including any necessary setup or configuration.

Register a long-running tool that mutates its tool context and returns nothing, then run an agent that calls it:

const startJob = new LongRunningFunctionTool({
  name: 'startJob',
  description: 'starts a background job',
  execute: async (_args, toolContext) => {
    toolContext!.state.set('pendingJob', 'job-123');
    return undefined;
  },
});

const runner = new InMemoryRunner({
  agent: new LlmAgent({
    name: 'job_agent',
    model: '<your model>',
    tools: [startJob],
  }),
  appName: 'demo',
});

Ask the agent to start the job and iterate the events. Before this change the run produced no tool event and session.state['pendingJob'] was undefined; now the run emits one event with content === undefined and actions.stateDelta = {pendingJob: 'job-123'}, the session state contains pendingJob, and the agent does not take an extra model turn while the call is pending.

Checklist

[x] I have read the CONTRIBUTING.md document.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] New and existing unit tests pass locally with my changes.

[AmaadMartin]

Automated: ported to upstream as google#571.