fix: strip id field from FunctionCall/FunctionResponse before sending to Gemini API

[YuqiGuo105]

Problem

Fixes #694

The Gemini API rejects requests that include an id field inside contents[].parts[].function_call or contents[].parts[].function_response, returning:

400 Invalid JSON payload received. Unknown name "id" at 'contents[5].parts[0].function_call': Cannot find field.
400 Invalid JSON payload received. Unknown name "id" at 'contents[6].parts[0].function_response': Cannot find field.

This surfaces in multi-turn / multi-agent workflows (e.g. Google ADK) where the SDK serializes FunctionCall and FunctionResponse objects that carry an id field populated from a previous model response. The field is valid on the inbound (model → client) side but is not accepted on the outbound (client → API) side.

---

Root Cause

The converter methods in the five converter files (Models, Batches, Caches, LiveConverters, TokensConverters) were copying every field from the type object into the outbound JSON, including id.

Before — functionCallToMldev in each converter copied id unconditionally:

// copied into outbound JSON — causes 400
if (Common.getValueByPath(fromObject, new String[] {"id"}) != null) {
  Common.setValueByPath(
      toObject,
      new String[] {"id"},
      Common.getValueByPath(fromObject, new String[] {"id"}));
}

Before — partToMldev passed functionResponse through as-is (including id):

Common.setValueByPath(
    toObject,
    new String[] {"functionResponse"},
    Common.getValueByPath(fromObject, new String[] {"functionResponse"}));

---

Fix

After — the id copy-block is removed from functionCallToMldev in all five files.

After — partToMldev converts functionResponse to a JsonNode and explicitly removes id before forwarding:

JsonNode functionResponseNode =
    JsonSerializable.toJsonNode(
        Common.getValueByPath(fromObject, new String[] {"functionResponse"}));
if (functionResponseNode instanceof ObjectNode) {
  ((ObjectNode) functionResponseNode).remove("id");
}
Common.setValueByPath(toObject, new String[] {"functionResponse"}, functionResponseNode);

The id field is intentionally kept in FunctionCall.java and FunctionResponse.java so the SDK can still deserialize it from inbound model responses.

---

Files Changed

File	Change
Models.java	Remove id from functionCallToMldev; strip id in partToMldev
Batches.java	Same
Caches.java	Same (2 occurrences of partToMldev)
LiveConverters.java	Same (2 occurrences of partToMldev)
TokensConverters.java	Same
FunctionCallIdStrippingTest.java	New test: 20 tests covering all 5 converters

---

Testing

Added FunctionCallIdStrippingTest.java with 20 JUnit 5 tests:

• id is stripped from FunctionCall in all 5 converters
• id is stripped from FunctionResponse in all 5 converters
• Non-id fields (name, args, response) are preserved
• FunctionCall/FunctionResponse type objects still deserialize id from JSON (regression guard)
• Edge cases: no id present, name-only function call

All 20 tests pass.