#1080 runModel(): options.arguments never reach the child's per-method arguments — merged into globalArgs, then dropped or rejected

Hi again! Second small finding from our context.runModel() migration today (same session as #1077 — and once more, thank you for this feature; the design is exactly what our nested-composition setup needed).

While converting our extensions we found that per-method arguments don't reach the child method in 20260710.223351.0. We hit it empirically first, then traced it in source at fb93097:

What we observe (two forms, two failures):

1. By-definition form: context.runModel({ definition: "cli-agent", method: "invoke", arguments: { prompt: "..." } }) → the child's invoke sees prompt: undefined and fails with "Method arguments validation failed".
2. By-type form (fresh name): → "Global arguments validation failed: Unknown argument(s): prompt, provider, ..." — the target's strict globalArguments schema rejects the method-arg keys outright.

Where it seems to come from:

• src/domain/models/model_invocation_service.ts:171-173 merges options.arguments over definition.globalArguments and passes the result as the child context's globalArgs — method args are never populated separately.
• src/domain/models/method_execution_service.ts:169 then reads the child's method arguments from the persisted definition (definition.getMethodArguments(context.methodName)), so the caller's arguments can never reach them; and the strict globalArgs validation (~line 133) rejects any method-arg keys that came along for the ride.
• design/models.md shows arguments: { cidrBlock: "[IP-1]/16" } flowing into a create method, which reads as the intended behavior — so this looks like an implementation gap rather than a design choice (though happy to be corrected!).

Impact for us: every composition we're migrating passes per-call data (prompts, PR lists, browser command batches), so today the runModel path fails validation for all of them. The silver lining: the validation failure fires before the method body runs, so we've shipped our conversions as runModel-first with a cheap fall-back to our old shell-out on that error — zero behavior change now, and the runModel path will light up on its own once argument threading works. So there's no urgency on our end, just wanted to flag it while it's fresh.

Could a fix perhaps thread options.arguments through to the method-args resolution (e.g. merged over definition.getMethodArguments(...) before validation), rather than into globalArgs? Whatever direction you prefer, of course. Happy to test a build against our real extension chain — we have four converted call sites that would exercise it immediately. Thanks so much!