feat(ffi): repair_tool_call for every binding via handles in opts_json

[cunninghamcard-bit]

Gives every binding the AI SDK repairToolCall hook that #165 landed for Rust callers only.

Problem

GenerateTextOptions.repair_tool_call is #[serde(skip)], so the C ABI's opts_json could not carry it and the seven bindings only ever saw the result of repair (ToolCallRepair, C code 17) — none could supply a repair function. The same was true of abort_signal, which is why aimux_stream_text_with_abort exists as a separate entry point.

Design

opts_json is the whole GenerateTextOptions object, the shape the AI SDK uses. Fields that hold live objects travel as handles and are resolved in parse_opts_arg before the rest deserializes:

{"tools": [...], "abort_signal": 7, "repair_tool_call": 42}

• aimux_tool_call_repair_new(fn, user_data) -> handle registers a host function with the repairToolCall contract: it receives {tool_call, error, input_schema, tools, messages, instructions} as JSON and returns the repaired RawToolCall JSON, {"error": "<message>"} to record a failure, or NULL to keep the original error; strings come from the new aimux_string_new and aimux frees them. Core parses and validates a returned call from scratch and records an error reply as ToolCallRepair { original_error, cause } — exactly what a Rust closure that returns Err gets, so all seven bindings have one error semantics. parse_tool_call is untouched.
• The host function runs synchronously on the thread that entered the aimux_* call, inside the existing re-entrancy guard: an aimux_* call from inside it fails with AIMUX_E_FFI_REENTRANT_CALL (204) instead of deadlocking — same rule as the stream callbacks, covered by a test.
• aimux_tool_call_repair_drop disarms clones held by in-flight calls (they behave as if the function returned NULL), so the host may release user_data after it returns. Handle 0 means "none", matching aimux_tool_call_repair_new(NULL).
• No existing entry-point signature changes. The explicit abort_handle of the *_with_abort variants still wins when both are given. Future callbacks are one more aimux_*_new constructor plus a JSON field.
• The RawToolCall / context / reply wire code lives once, in aimux-core (RawToolCall derives serde, ToolCallRepairContext::to_wire_json, parse_repair_reply); the C, Node and Python bridges all use it.

Each binding exposes a ToolCallRepair built from a native function and sets it on its GenerateTextOptions (repairToolCall / repair_tool_call), where it serializes as the handle. Registered objects stay alive until close() (Java/Kotlin static registry, Swift passRetained, Go cgo.Handle, Dart NativeCallable + @pragma('vm:isolate-unsendable') so an Isolate.run hand-off fails fast instead of crashing). Node and Python link Core directly and bridge the function natively (napi ThreadsafeFunction; PyO3 on a spawn_blocking thread with the calling thread's GIL released) — in both, the hook may itself call aimux.

Verification

Layer	Local	Notes
aimux-ffi	clippy clean; 129 tests incl. contract	repair fixes / gives up / error envelope / re-enters (204) / bad handle (203) / non-integer (5) / handle 0 / dropped clone not invoked / abort_signal via JSON / same on the aimux_stream_text path
Go	vet + full suite	reference host implementation; repair via StreamText; nested aimux call refused as re-entrant
Java	113 tests, JUnit run directly on JDK 21	gradle needs JDK 17 (CI)
Kotlin	79 tests on JDK 21
Node	91 tests	JS repair may call back into aimux (tested); a reply that is neither a call nor {error} is a ToolCallRepair error
Python	89 tests via maturin	hook runs on a blocking thread, GIL released on the caller; may call back into aimux (tested); a non-dict reply is a TypeError recorded as the repair cause
Swift	library builds; new test expressions type-checked	no XCTest here
Flutter	not run	no dart toolchain here; CI is the first run

Docs: docs/api/{c,go,java,kotlin,swift,flutter,node,python}.md.

Follow-ups tracked separately in #185 (ToolInput raw/parsed enum, unused StreamingToolCallTracker).