Convert every POST off multipart — 21 call sites across 7 tabs

A multipart POST to the plugin API hangs and never completes on this host: no
status code, and no server-side trace of any kind. The correlation was exact —
every page using URLSearchParams worked, every page using FormData hung, which
is why scheduler and partnership appeared fine while docker, rsync, settings,
auth, arrs, fallback and monitor did not. URLSearchParams has the same append
API and fetch sets the urlencoded content type for it, so each site is a
one-token change with the payload logic untouched.

Plugin/unraid/README-unraid.md

@@ -159,6 +159,33 @@ is already covered by a different platform mechanism: dynamix's `BodyInlineJS.ph
 hidden `csrf_token` input to every form on the page, which is what makes `VaraverkSettings.page`
 work without any of this.
 
+### Never send a POST as multipart/form-data
+
+**`FormData` is banned in this plugin.** A `multipart/form-data` POST to the plugin API *hangs
+and never completes* on this host — confirmed 2026-08-02.
+
+The failure is completely silent, which is what makes it dangerous:
+
+- The browser sends it correctly, valid token and all (verified in the Network tab).
+- The Network row shows **no status code at all** — not 403, not 500. It never completes.
+- Server side there is nothing: no CSRF termination in syslog, no fatal in `/var/log/phplog`,
+  and no output from a log statement that is the literal first line of the endpoint.
+
+Use `URLSearchParams`. `fetch` sets `application/x-www-form-urlencoded` for it automatically,
+and it has the same `append()` / `set()` API, so it is a drop-in for any payload of strings:
+
+```js
+const fd = new URLSearchParams();      // NOT new FormData()
+fd.append('action', 'save');
+fetch(url, { method: 'POST', body: fd });
+```
+
+The correlation across the plugin was exact: every page using `URLSearchParams` worked, every
+page using `FormData` hung. All 21 call sites were converted in one pass. Suspected to date from
+the Unraid 7.3.1→7.3.2 upgrade; root cause in nginx/php-fpm was never identified, only the
+workaround. If a POST ever hangs with no status code and leaves no server-side trace whatsoever,
+**suspect the encoding first** — not CSRF, not auth, not the endpoint.
+
 ### api/webhook.php is dead code
 
 It receives arr download events — but an arr has no WebGUI session and no CSRF token, so it is