Fix the mid-stream cut in antigravity harness on substrate

[wjjclaud]

Investigate the root cause and submit a fix of the following issue:

During my test with antigravity on substrate, I sometimes got a response cut mid-stream in a turn, and the next turn continues the stream response from the previous turn. For example:

• User: what about LA?
• Harness: It
• User: what about LA?
• Harness: appears that weather information for Los Angeles (LA) is currently not available.
  Weather information for Los Angeles (LA) is unfortunately not available in the weather
  database at the moment.
  If there is another city you'd like to check, please let me know!

[wjjclaud]

Tried to reproduce the bug with some logs:

seq 21  toolCall get_weather(Los Angeles)
seq 22  stepUpdate STATE_ACTIVE  source=MODEL target=USER  text="The"          ← chunk #2 ("The")
seq 23  trajectoryStateUpdate    STATE_IDLE                                      ← idle fires HERE
seq 24  stepUpdate STATE_DONE    source=MODEL target=USER  text="The weather information for **Los Angeles** is currently unavailable."   ← the COMPLETE response, 1ms LATER

The localharness emits STATE_IDLE (seq 23) one message before the final STATE_DONE step (seq 24) that carries the complete answer. The antigravity SDK marks the connection idle on seq 23, and its receive_steps/response.chunks exits on idle + empty queue. So the harness's chunk loop stops after the partial text "The" (seq 22).

We could have a defensive check on conversation.last_response after the harness's chunk loop. But the root cause is the race from the SDK.

[wjjclaud]

cc @rakyll @anj-s @joycel-github

[joycel-github]

+1 that race condition on antigravity sdk. local connection codes is using idle + empty queue to make judgement which prob is not necessary correct https://github.com/google-antigravity/antigravity-sdk-python/blob/main/google/antigravity/connections/local/local_connection.py#L574