fix(llm): preserve opaque tool-call fields

[vincekent]

Description

Preserve unknown JSON fields returned on OpenAI-compatible function tool calls and echo them on later assistant-history turns through the OpenAI SDK's supported SetExtraFields mechanism.

Vertex AI's OpenAI-compatible Gemini endpoint puts a required thought signature under tool_calls[].extra_content. OCR previously reduced every returned tool call to id, type, and function, so a repository tool succeeded on turn one and the provider rejected turn two with HTTP 400. The fix is provider-independent: opaque extension fields survive the response-to-request round trip, while OCR continues to own id, type, and function; invalid JSON is not forwarded; and the fields remain excluded from normal OCR JSON/session serialization.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

• make test passes locally
• Manual testing (describe below)

Tests and validation:

• go test -count=1 ./internal/llm -skip 'TestShellRCFiles|TestTryShellRC' passes. The skipped tests are existing Unix-home assumptions that fail under Windows because os.UserHomeDir does not follow the test's HOME override.
• go vet ./... passes.
• Added an HTTP-level regression test: a fake OpenAI-compatible server returns nested opaque extra_content on turn one and rejects turn two unless OCR echoes it unchanged.
• Built the patched OCR binary and ran a real three-file review against Vertex AI's official OpenAI-compatible Gemini endpoint. Before this patch, all three files failed on request two with HTTP 400 and coverage was 0/3. With this patch, coverage was 3/3, the review completed, and it found the planted defect. Two additional identical runs also completed 3/3, proving the transport/tool loop is stable.
• Ran OCR's required self-review command against this diff; it completed with no findings.

The full Windows suite still contains unrelated permission/Unix-shell failures, and the race target requires a CGO toolchain not present on this host. CI remains the authoritative full race run.

Checklist

• My code follows the project's coding style (go fmt, go vet)
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or my feature works
• New and existing focused unit tests pass locally with my changes
• I have updated the documentation accordingly (not applicable; no user-facing configuration changes)
• I have signed the CLA

Related Issues

Closes #947

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

✅ OpenCodeReview: Review complete: 0 finding(s) across 1 selected item(s).

[vincekent]

Fresh staging evidence after the Pylon Vertex route fix: real webhook run 6268865c14c35ca78fc44dce1b528a6c on immutable agent revision 01a00a63-e57a-7613-b311-2c95d45c620a created one E2B sandbox and invoked OCR with google/gemini-3.7-flash. OCR selected both changed files, but both file reviews failed and the run ended with all 2 file review(s) failed, zero usable model tokens, and no publication. The route itself is now proven working; the deployed template still pins OCR v1.9.3 and lacks this opaque tool-call-field preservation fix. Please keep this PR open for upstream review. The existing HTTP regression and three successful patched real-Gemini runs remain the direct transport proof.