feat(core): ToolApprovalRequestOutput.inputSchemaInput (phase 1 unit 1.2)

[cunninghamcard-bit]

Phase 1 unit 1.2 (reworked per the corrected reading: arcships#200:1952 is about the model-message content parts).

• Content part: ContentPart::ToolApprovalRequest (aimux-core/src/content.rs:48-63), which is the prompt / model-message part read by language_model_message.rs, already has optional camelCase inputSchemaInput. A new round-trip test covers it with the field (object and raw-string values) and without it.
• Output type: ToolApprovalRequestOutput (result.rs) carries input_schema_input internally only (#[serde(skip)], #[ts(skip)]). Its public JSON and the ts-rs binding are unchanged from the base; a test checks the field is neither read from nor written to JSON.
• Response messages: response_messages.rs writes inputSchemaInput into the tool-approval-request part only when it is not deep-equal to toolCall.input, mirroring AI SDK to-response-messages.ts:134-144 (isDeepEqualData). Unit tests cover unequal (present), equal (absent) and none (absent).
• No host approval runtime: core construction sites set None (docs: full-chain AI SDK alignment design and impact map arcships/aimux#200 §0.4 Q1, pass-through only).

Hand-written bindings (D20 corrected). No gap. Every prompt / content part already carries inputSchemaInput: Kotlin Types.kt:485, Java Types.java:1510, Swift Types.swift:651, Flutter types.dart:832, Python wrapper.py:662. The locations previously listed are all output / stream types, which by design carry no inputSchemaInput, matching the Rust output JSON:

• Types.kt:1087 StreamPart.ToolApprovalRequest
• Types.swift:900 ToolApprovalRequestOutput
• types.dart:1900 StreamPartToolApprovalRequest
• wrapper.py:370-376 _ApprovalRequest
• Types.java:4497 StreamPart.ToolApprovalRequest

Note: this branch is cut from exp/unit2-ci so that CI triggers, so the diff against exp/restart also includes unit 2's ci.yml change.