fix(opencode): coerce stringified JSON arrays/objects in tool parameters

[crottolo]

Fixes #7512

Problem

LLMs sometimes send tool parameters as strings instead of proper typed values:

{ "todos": "[{...}]" }    // string instead of array
{ "timeout": "180000" }   // string instead of number  
{ "enabled": "true" }     // string instead of boolean

This causes Zod validation to fail with expected X, received string.

Solution

Added automatic coercion in Tool.define():

1. First attempt normal validation with safeParse
2. If fails with type error, coerce string values:
   • [ or { prefix → JSON.parse() for arrays/objects
   • Numeric string → Number() for numbers
   • "true"/"false" → boolean conversion
3. Retry validation with coerced values
4. If still fails, throw original error (backward compatible)

Verification

Tested all affected tools:

✅ Bash (timeout: number)
✅ Todowrite (todos: array)
✅ Webfetch (timeout: number)
✅ Websearch (numResults: number)
✅ LSP tools (line, character: number)
✅ Read (offset, limit: number)
✅ Normal typed values still work unchanged

Scope

• 10+ tools affected: Bash, Todowrite, Question, Webfetch, Websearch, LSP, Edit, Multiedit, etc.
• All providers: Anthropic, OpenAI, Google, etc.
• Backward compatible: Yes

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, the only related PR that came up alongside PR #7513 is:

PR #4715: "fix(write): support array content from Venice.ai models"

• fix(write): support array content from Venice.ai models #4715

This PR appears related as it also deals with handling array content from LLM models, which touches on similar issues of how arrays are passed and validated in tool parameters.

However, this is an older PR (from the numbering), and the current PR #7513 appears to be a more comprehensive solution addressing stringified JSON in general (not just Venice.ai), with proper coercion logic using Zod's safeParse and JSON.parse().

The searches did not reveal any open PRs directly duplicating the current PR's scope. The current PR (#7513) is the most recent one addressing this stringified JSON coercion issue.