Align shared JSON types with the AI SDK

[peter-research]

Summary

The current public CI fails during SDK declaration bundling with multiple TypeScript errors in message conversion and streaming code. They share the same cause: the local JSON value type models only mutable objects/arrays, while the AI SDK's provider options also use readonly JSON objects and arrays.

• Align the shared JSONValue and JSONArray definitions with readonly JSON values.
• Add a type-compatibility regression test between ToolModelMessage.providerOptions and the shared ProviderMetadata type.

This keeps the JSON schema validation in place and fixes compatibility at the shared type boundary rather than adding casts to affected call sites.

Verification

Reproduced the failure from the latest Public CI log for Build SDK (TypeScript errors in common/src/util/messages.ts, packages/agent-runtime, and sdk/src/impl/llm.ts). The Bun test suite has not been run locally; CI still needs to validate the fix.

[codebuff-team]

Thanks for this — the diagnosis is sound: AI SDK's ProviderOptions/JSONValue types use readonly arrays/objects, and if the local JSONValue/JSONArray definitions require mutable arrays, structural assignability breaks at any boundary where SDK types flow into local ones (e.g. ToolModelMessage.providerOptions → ProviderMetadata). Widening to readonly JSONValue[] and Readonly<JSONObject> is the right fix at the type-definition level rather than scattering as casts at call sites, and the added test in json-provider-compatibility.test.ts meaningfully pins the compatibility contract instead of just asserting it compiles.

A few things worth double-checking before porting:

• jsonArraySchema/jsonValueSchema are runtime Zod schemas, not just types — confirm z.array(jsonValueSchema) output type still unifies with the new readonly JSONValue[] without requiring an explicit cast internally (Zod's inferred array type is typically mutable, so z.ZodType<JSONArray> may now need .readonly() or equivalent to type-check cleanly).
• Please run the full common package's typecheck/test suite locally if possible — you noted Bun tests haven't been run, and this change touches a widely-used shared type, so ripple effects in other call sites that assume mutable JSONArray/JSONObject (e.g. code that does .push() or in-place mutation on a JSONArray) need to be checked for new compile errors.
• Worth confirming no other locations reference JSONObject expecting mutability directly (spread into a mutable object is fine, but direct .someProp = x assignment would now fail, which is probably desirable but should be an intentional check).

Small, targeted, and testable — good first contribution. Flagging the Zod-schema interaction as the main risk area a maintainer will want verified.