Windows (new arch): fetchBlobForm multipart POST is sent as GET regardless of method

[FaithfulAudio]

Environment

• react-native-blob-util (windows module), consumed from a react-native-windows 0.83.2 new-architecture (Fabric) app, framework built from source
• Windows 11, ARM64 and x64 reproduced
• App: production line-of-business app (Facilitron FIT)

Summary

Calling ReactNativeBlobUtil.fetch('POST', url, headers, bodyArray) (the multipart
fetchBlobForm path) on Windows sends the HTTP request with method GET, not POST.

Evidence

• JS call site (simplified):

  await ReactNativeBlobUtil.fetch(
    'POST',
    'https://api.example.com/Attachments/WorkOrders/3764993',
    { Authorization: `Bearer ${token}`, 'Content-Type': 'multipart/form-data' },
    [{ name: 'formFiles', filename: 'photo.png', type: 'image/png', data: ReactNativeBlobUtil.wrap(path) }]
  )

• The server (ASP.NET Core, [HttpPost("WorkOrders/{workOrderId}")]) answers 405
  Method Not Allowed with Allow: POST.

• Server-side telemetry (Azure App Insights) logs the arriving request as
  GET /Attachments/WorkOrders/3764993 — for every attempt, on two separate
  server deployments. curl -X POST against the same URL reaches the action
  normally, so this is not server routing.

• The same app's fs.readFile, fs.writeFile and download paths (GET) work fine.

What we could and couldn't pin down

Reading the current windows/ReactNativeBlobUtil/ReactNativeBlobUtil.cpp, the
fetchBlobForm method mapping looks correct (HttpMethod::Post() default, GET only
when the string compares equal to "GET"/"get"), and the codegen spec's argument order
(options, taskId, method, url, headers, form, callback) matches the C++ signature. So
either the binary we ship diverges from the current source, or the method argument
does not arrive as "POST" through the new-architecture marshaling path (we did not
step through the native side). We can say definitively that the wire method is GET
while JS passes 'POST'.

Workaround

We stopped using multipart on Windows entirely — the API now exposes JSON/base64
sibling endpoints and files are posted through axios. That works, but it means
fetchBlobForm is effectively unusable on Windows new-arch.

Ask

• Confirm whether fetchBlobForm is expected to work on RNW new-architecture, and
  whether the method argument is known to marshal correctly there.
• If useful we can provide a minimal repro app and packet captures.