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

• Closes: #1416

2. Or, if no issue exists, describe the change:

Problem:

LlmResponse.Builder.response(GenerateContentResponse) decides success by testing whether the
candidate's content object is present, never whether it holds anything. A candidate cut off
mid-generation arrives with content present and part-less ("content": {} on the wire), so
candidate.content().isPresent() sends it down the success branch: errorCode and errorMessage
stay empty, and finishMessage is discarded. The caller receives an empty answer that reads exactly
like a model with nothing to say.

errorCode is documented as "Error code if the response is an error", yet the result carries
finishReason=MAX_TOKENS with errorCode empty.

Solution:

One predicate. Decide on whether the candidate produced parts, and treat a STOP with nothing to
say as a legitimate empty turn:

Candidate candidate = candidatesOpt.get().get(0);
this.finishReason(candidate.finishReason().orElse(null));
boolean hasParts =
    candidate.content().flatMap(Content::parts).map(parts -> !parts.isEmpty()).orElse(false);
boolean stopped =
    candidate.finishReason().map(reason -> reason.knownEnum() == FinishReason.Known.STOP).orElse(false);
if (hasParts || stopped) {
  this.content(candidate.content().orElse(null));
  this.groundingMetadata(candidate.groundingMetadata().orElse(null));
} else {
  candidate.finishReason().ifPresent(this::errorCode);
  candidate.finishMessage().ifPresent(this::errorMessage);
}

Two rows of behavior change, both in this branch:

Everything else is untouched: parts present is still a success whatever the reason, a part-less
STOP still succeeds, a blocked prompt still becomes errorCode from blockReason, and the
no-candidates path is unchanged.

Testing Plan

Unit Tests:

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

Eight in LlmResponseTest. The four marked as failing were confirmed failing on unmodified main
before the change, by reverting LlmResponse.java alone and re-running:

The four that already pass are the guards. They describe behavior this change must leave alone, so
they only break if the classification is inverted rather than tightened.

Manual End-to-End (E2E) Tests:

• A real LlmAgent on gemini-3.1-flash-lite with maxOutputTokens=24 and
  thinkingBudget=2048 returns a part-less MAX_TOKENS candidate on demand. Before the change it is
  reported as a success and the caller receives an empty answer; after it, the same response carries
  errorCode=MAX_TOKENS. A control arm on an ordinary budget answers normally in both runs, and a
  truncated-but-non-empty answer stays a success in both.

Checklist

• I have read the CONTRIBUTING.md document.
• My pull request contains a single commit.
• 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.