fix(translator): preserve additionalProperties: true for Gemini schemas (#12509)

[KooshaPari]

Summary

Fixes #12509

Gemini API `function_declarations` rejects `additionalProperties: false` with HTTP 400 "Unknown name", but accepts (and honors) `additionalProperties: true` — strict-by-default validation on top of the explicit properties list, exactly the case where the caller wants Gemini to error on unknown input.

The current `normalizeAdditionalProperties()` in `open-sse/translator/helpers/geminiHelper.ts` unconditionally deletes the key regardless of value — so a tool author who explicitly opts into strict validation gets the opposite of what they asked for.

Fix

```diff

• if ("additionalProperties" in record) {

• if (record.additionalProperties === false) {
  delete record.additionalProperties;
  }
  ```

Input	Before	After
`false`	stripped	stripped (Gemini 400 otherwise)
`true`	stripped (wrong)	preserved (Gemini honors strict)
absent	unchanged	unchanged
non-boolean	stripped	unchanged (let Gemini surface its own error)

Fixes #12509

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[diegosouzapw]

Thanks for digging into #12509 — but I have to close this one, because the diff argues against itself.

The change narrows the strip to additionalProperties === false, and the new comment says of the true case:

Gemini rejects with 400 in that case too, so we keep the original error path rather than silently masking it.

That is the exact failure #1421 removed. Gemini function_declarations schemas reject the additionalProperties key, not a particular value — the current unconditional strip is what keeps a client that sends additionalProperties: true from getting a 400 Unknown name. Preserving it as "a positive signal that the caller wants strict validation" does not reach Gemini as a signal; it reaches Gemini as an unknown field.

If the goal is to stop silently discarding caller intent, the place for that is a translator-level warning or a strict-mode mapping onto something Gemini actually understands — not re-sending the field that provokes the error.

Reopening is welcome if you have an upstream response showing Gemini now accepts additionalProperties: true; that would change the premise and I would take it.