FIX: warn instead of raising on reasoning-model token truncation

[romanlutz]

Description

Reasoning models spend completion tokens on hidden reasoning before emitting any visible output. When max_completion_tokens is set too low, the API can return finish_reason="length" with empty visible content. OpenAIChatTarget._validate_response treated that empty content as a hard failure and raised EmptyResponseException (surfaced with a misleading "Status Code: 204"), which also triggered the full retry loop even though retrying with the same token budget cannot succeed.

Since a low token budget can be a deliberate configuration choice, this changes the behavior to warn rather than raise:

• On any finish_reason="length", log a warning explaining that reasoning models consume tokens on hidden reasoning and that max_completion_tokens may need to be increased.
• When the truncation left no visible content, return a graceful empty response (error="empty") so the run continues instead of raising and retrying.
• Responses that are empty for other reasons still raise EmptyResponseException as before.

The final stored result for the empty case is unchanged from today (an error="empty" piece). The difference is no exception, no retry storm, and a clear warning pointing at the token limit.

Tests and Documentation

• Updated test_validate_response_success_length to assert the truncation warning is emitted when content is present.
• Added test_validate_response_length_empty_returns_empty_response asserting that a truncated-and-empty response returns a Message with error="empty" and raises nothing.
• Full tests/unit/prompt_target/target/test_openai_chat_target.py suite passes (101 tests).

No documentation changes needed. JupyText not run (no doc or notebook changes).

[bashirpartovi]

Here a truncated response with partial content falls through to capture_token_usage, but the truncated-empty case returns before we capture anything. I think that's the case where usage is most valuable which means the whole max_completion_tokens budget was spent (probably on reasoning) with no visible response text, and usage is populated on length-finish responses so we can actually recover it.

Also capture_token_usage already no-ops when there's no usage or no pieces so capturing on the empty path is easy thing to do for compatible providers that omit usage:

if choice is not None and getattr(choice, "finish_reason", None) == "length":
    empty_message = construct_response_from_request(
        request=request,
        response_text_pieces=[""],
        response_type="text",
        error="empty",
    )
    capture_token_usage(pieces=empty_message.message_pieces, response=response)
    return empty_message

[bashirpartovi]

One other comment here is that we are stripping away the truncation reason. Anything downstream cannot tell whether this is a normal empty message or it is a truncated message, that's why it is empty. This might be useful to know for Scorers or Attacks. Maybe we could add something like piece.prompt_metadata["truncated"] = True