fix(uploads): read the body after authenticating, not before it

`POST /api/downloads/upload` declared `file: UploadFile = File(...)`, and
FastAPI parses and spools a declared body before the first dependency runs --
`require_human` included. An unauthenticated caller could therefore make the
process write the whole per-file allowance (500 MiB by default) to temp, once
per request. SEC-20's ceiling bounded that number but could not stop the
writing, which is why E27 parked it rather than closing it.

The route now takes no body parameter. `spool_upload` names `require_human`
first and only then streams `request.stream()` to the staging temp file, so a
stranger is refused before a byte moves -- the shape the screenshot route has
used since E16. Filename and display name travel as percent-encoded headers
(latin-1 on the wire, so a Hungarian filename needs the encoding) instead of
multipart parts.

`capped_stream_to` joins `capped_body` in routes/_common.py: the same counting
rule, written to a file descriptor rather than accumulated, because holding
500 MiB would trade a disk problem for a memory one. Its refusal is the
caller's, so the upload route keeps answering 422 `upload_too_large` with the
admin knob's own number.

With no envelope to allow for, the edge is now exactly that knob, and
MULTIPART_ENVELOPE_ALLOWANCE is gone.

The invariant stops being prose: test_body_limit.py asks FastAPI itself
(`route.dependant.body_params`) and fails the gate if any route with a raised
ceiling declares a body. A comment could not have prevented the defect it
described; that test would have.

Both new tests were seen red for the right reason -- before the fix the
anonymous probe got its 401 only after the server had read 4236 bytes of a
multipart body, and re-declaring the File parameter turns the invariant test
red naming the route and the parameter.

frontend/src/lib/api/downloads.ts

@@ -187,16 +187,23 @@ export const downloadsApi = {
   // Ingest a local file into the library (E7 S5). Multipart via XHR so the dialog can show upload
   // progress; any file type is accepted (media gets the full function set, a generic file is
   // download-only). Returns the already-`done` job the ingest creates.
+  // The body IS the file, and the two names ride as headers. Not a style choice: a multipart part is
+  // a DECLARED body, which FastAPI reads and spools BEFORE the route's `require_human` dependency
+  // runs — so with the old shape an unauthenticated caller could make the server write the whole
+  // per-file allowance to temp (P1). Headers are latin-1 on the wire, hence `encodeURIComponent`;
+  // the server percent-decodes both. Content-Type is left to the browser (the File's own type).
   uploadDownload: (
     file: File,
     opts: { displayName?: string; onProgress?: (pct: number) => void; signal?: AbortSignal } = {},
   ): Promise<DownloadJob> => {
-    const form = new FormData();
-    form.append("file", file);
-    if (opts.displayName) form.append("display_name", opts.displayName);
-    return uploadReq<DownloadJob>("/api/downloads/upload", form, {
+    const headers: Record<string, string> = {
+      "X-Upload-Filename": encodeURIComponent(file.name || "upload"),
+    };
+    if (opts.displayName) headers["X-Upload-Display-Name"] = encodeURIComponent(opts.displayName);
+    return uploadReq<DownloadJob>("/api/downloads/upload", file, {
       onProgress: opts.onProgress,
       signal: opts.signal,
+      headers,
     });
   },
   enqueueEdit: (body: {