fix: pass tool result content through as string in OpenAI/Claude -> Gemini translation

[Hsia97]

Summary

Tool results that are themselves valid JSON (e.g. a WebFetch payload {"title": ..., "summary": ...}) were JSON.parse'd and nested into functionResponse.response.result as a structured object by both Gemini request translators. Antigravity rejects that shape with HTTP 400 "upstream error".

This change stops parsing tool result content entirely: the raw string is passed through unchanged as response.result, and plain-text results are no longer double-wrapped as { result: { result: ... } }.

• open-sse/translator/request/openai-to-gemini.ts — drop the tryParseJSON dance on tool result content; emit response: { result: resp }.
• open-sse/translator/request/claude-to-gemini.ts — same for tool_result content; remove the now-unused tryParseJSON import.
• openai-to-gemini.ts keeps parsing function call arguments (fn.arguments) — that path is untouched.

Related Issues

• No issue was filed for this regression; reported directly with a local reproduction.

Validation

Change type: other (request-translator conversion)

• Change type: other (request-translator conversion)
• Focused tests and category gates from the golden path — translator unit suites + new regression suite below
• npm run lint — full lint runs in CI; the changed files are eslint-clean (--max-warnings 0, exit 0)
• Reconciled with the current active release base: branch cut from release/v3.8.51 tip e0ea3f9; focused checks rerun after the change
• Production-code changes include a new or updated automated test in this PR

Evidence — translator suites (includes the new regression tests):

ℹ tests 68
ℹ pass 68
ℹ fail 0
✔ OpenAI -> Gemini keeps a JSON-string tool result as a raw string
✔ OpenAI -> Gemini keeps a plain-text tool result as a raw string (no double wrap)
✔ OpenAI -> Antigravity keeps a JSON-string tool result as a raw string
✔ Claude -> Gemini keeps a JSON-string tool_result as a raw string
✔ Claude -> Gemini keeps a plain-text tool_result as a raw string (no double wrap)

Evidence — open-sse typecheck gate and test discovery (the local runner is Windows 24 where npx.cmd spawnSync is EINVAL — same class of issue the repo's Windows build scripts already accommodate — so tsc was invoked directly with identical flags and the same baseline diff):

LIVE-ERRORS=5
NO-REGRESSIONS (all live errors within frozen baseline)
[test-discovery] OK — 5182 arquivos de teste, 31 collectors, 13 órfão(s) congelado(s)

Tests Added Or Updated

• tests/unit/translator-tool-result-json-passthrough.test.ts (new): JSON-string and plain-text tool results stay raw strings through OpenAI→Gemini, OpenAI→Antigravity (Cloud Code envelope) and Claude→Gemini request translation.
• tests/unit/translator-openai-to-gemini.test.ts: 3 expectations updated to the new shape ({"temp":20} stays a string; "The answer is capybara-4729." is no longer double-wrapped; '{"ok":true}' stays a string).
• tests/unit/translator-claude-to-gemini.test.ts: 1 expectation updated ("20C" is no longer double-wrapped).

Coverage Notes

• The change is confined to open-sse/translator/request/ conversion. The two translator suites plus the new passthrough suite assert the exact emitted functionResponse.response shape on both the OpenAI and Claude input paths, including the Cloud Code envelope used for Antigravity.
• The deleted parse branches were removed, not replaced — no coverage regression.
• The emitted response: { result: <string> } shape is exactly what the response-direction translators already consume (gemini-to-openai-function-response.test.ts uses response: { result: "b done" }), so round-trips are consistent.

Reviewer Notes

• Observable behavior change: functionResponse.response.result is always the raw string now — for JSON-looking and plain-text tool results alike, on both translators.
• The double-wrap of plain-text results ({ result: { result: "20C" } } → { result: "20C" }) is removed intentionally; the outer { result: ... } wrapper stays because Gemini's FunctionResponse.response is an object.
• Inherited base-red note: on the current release/v3.8.51 tip (e0ea3f9, dependabot deps: bump the development group across 1 directory with 8 updates #11428, 2026-08-26) the known-symbols and mutation-test-coverage gates in Fast Quality Gates fail for ANY PR cut from this base: both reproduce identically on a pristine e0ea3f9 checkout (verified locally, zero PR changes applied). This PR touches neither executors/providers (known-symbols) nor routeGuard/combo-quota modules (stryker testFiles); the failures are the inherited base-reds tracked by fix(ci): resolve inherited release/v3.8.51 base-red CI failures #11608, chore(ci): unblock quality gates - env-doc sync + stryker tap.testFiles registration (#9282) #11609 (merge-ready, all green) and fix(autoCombo,sse): drop vendor-retired ids from the auto-combo pool and skip leftover arena_elo (#11625) #11626. The unit-shard and docs-gates flakes on the first CI run are also environmental (missing better_sqlite3.node native binary on the runner; docs gates pass locally on the identical tree).