sdk call: validate --args against the operation schema instead of passing malformed requests through

[altaywtf]

Problem

sdk call --args accepts input that doesn't match the operation's schema and silently builds a broken request, surfacing a misleading downstream API error instead of an input error.

Reproduction (authenticated, file exists and is readable):

putio sdk call --operation files.get --args '[1607632314]' --execute
# → {"error":{"title":"File not found", ...}}

putio sdk call --operation files.get --args '[1607632314, {"media_info": 1}]' --execute
# → {"error":{"title":"File not found", ...}}

putio sdk call --operation files.get --args '[{"id":1607632314,"query":{"media_info":1}}]' --execute
# → works, returns the file

The positional forms lose the id (request presumably goes out with an undefined id), and the API's 404 is passed through as "File not found". This cost a real debugging session today: the error convincingly suggested a permissions/token problem or a deleted file, when the actual issue was arg shape. Note the asymmetry: --json already rejects schema mismatches ("Expected --json to match the command input schema."), but --args does not.

Expected

--args input is validated against the operation's input schema before dispatch, like --json. A shape mismatch fails closed with a validation-kind error naming the expected shape (ideally echoing the schema), never a downstream API error.

Notes

• --dry-run also happily echoes the invalid shapes back, reinforcing the wrong impression that the request is well-formed.