OpenAPI multipart file fields are serialized as plain form fields

[NickChristensen]

Summary

Executor appears to mishandle file inputs for OpenAPI multipart/form-data tools. The Paperless upload endpoint is the repro case, but the likely bug is general OpenAPI file-part coercion: a file field is being sent as a normal form field instead of a real multipart file part with bytes/filename/content type.

Repro

1. Use Executor v1.5.32 with an OpenAPI source that has a multipart file upload operation.
2. For a concrete repro, use Paperless-ngx POST /api/documents/post_document/
3. Call the tool with the PDF as the document field, trying either a ToolFile-shaped value or byte-array/file-path style CLI input.

Expected

Executor sends document as a real multipart file part containing the PDF bytes, filename, and application/pdf content type. Paperless accepts the upload and creates a document.

Actual

Paperless returns HTTP 400:

{"document":["The submitted data was not a file. Check the encoding type on the form."]}

Investigation Notes

• Tool schema currently exposes document: string in PostDocumentRequest, despite the endpoint requiring a file upload.
• Tried ToolFile, byte-array payload, and @/tmp/file.pdf style CLI input; all produced the same Paperless validation error.
• This likely belongs in the OpenAPI request-body / multipart serialization path, not in the Paperless integration specifically.
• Relevant area to inspect: OpenAPI operation binding/schema generation for file fields plus runtime multipart coercion (coerceFormDataRecord / request body dispatch). The generated tool may be losing file semantics before runtime has a chance to build the correct multipart part.