Support for multipart/related content type (RFC 2387)

Summary

Progenitor doesn't support multipart/related content type, required by Google Workspace APIs (Drive, Gmail) for uploads combining JSON metadata with binary content. This is distinct from multipart/form-data (issue #518).

Use Case

Google Drive API uploads use multipart/related:

POST /upload/drive/v3/files?uploadType=multipart
Content-Type: multipart/related; boundary=foo_bar_baz

--foo_bar_baz
Content-Type: application/json; charset=UTF-8

{"name": "document.txt", "mimeType": "text/plain"}
--foo_bar_baz
Content-Type: text/plain

[file content]
--foo_bar_baz--

Key difference from multipart/form-data: Uses Content-ID references instead of field names, no Content-Disposition headers required (RFC 2387 vs RFC 7578).

Current Error

requestBody:
  content:
    multipart/related:
      schema:
        type: object
        properties:
          metadata: {$ref: '#/components/schemas/FileMetadata'}
          file: {type: string, format: binary}

Error: UnexpectedFormat("unexpected content type: multipart/related")

Current Workaround

Using application/octet-stream with manual multipart construction loses:

• OpenAPI contract for request structure
• Type safety for metadata schema
• Request validation

Desired Generated Code

client
    .upload_file_multipart()
    .metadata(FileMetadata { name: "doc.txt".to_string(), ... })
    .file(file_bytes)
    .send()
    .await?

Impact

Affects Rust clients for:

• Google Workspace APIs (Drive, Gmail, etc.) - major enterprise use case
• Any API using RFC 2387 for compound documents

We're happy to test implementations and provide additional examples!

References

• RFC 2387: https://www.ietf.org/rfc/rfc2387.txt
• Google Drive API: https://developers.google.com/drive/api/guides/manage-uploads
• Related: #518, #418 (multipart/form-data)

Start by reviewing the existing multipart/form-data work referenced by issues #518 and #418, then compare its generation path with RFC 2387. Use the Google Drive example as the behavior reference. Done means multipart/related is accepted and generated Rust clients can express metadata and binary content without the current UnexpectedFormat error.