docs(policies): cut the uploadableFile comments back to what the code cannot say

The docblock restated the WebKit mechanism at a level of detail the bug report
already holds, and the call-site and test comments repeated it a third and
fourth time. Keep the contract, the reason, the bug link, and the fact that the
wrapper references rather than copies the bytes; the function name carries the
rest.

Author: EthanHealy01

frontend/editor/src/core/utils/uploadableFile.test.ts

@@ -1,7 +1,7 @@
 import { describe, expect, it } from "vitest";
 import { uploadableFile } from "@app/utils/uploadableFile";
 
-/** jsdom's Blob has no text(); FileReader is the one byte read it implements. */
+/** jsdom's Blob has no text(). */
 const textOf = (file: File) =>
   new Promise<string>((resolve, reject) => {
     const reader = new FileReader();

frontend/editor/src/core/utils/uploadableFile.ts

@@ -2,20 +2,12 @@
  * The File to put in a multipart body when the caller's File may have come back
  * from IndexedDB.
  *
- * WebKit stamps a File restored from IndexedDB with a disk path into its own
- * storage folder, and its form serialiser reads any File with a path from disk.
- * Since Safari 26.5 the process doing the upload may not read that folder, so
- * the request goes out with Content-Length 0 and no error, while the same File
- * reads its bytes fine in JavaScript (https://bugs.webkit.org/show_bug.cgi?id=319985).
- * The server sees a multipart request with no boundary and rejects it before
- * any controller runs.
- *
+ * WebKit serialises such a File by reading the disk path it stamped on it, which
+ * since Safari 26.5 the uploading process may not read: the request goes out with
+ * Content-Length 0 and no error (https://bugs.webkit.org/show_bug.cgi?id=319985).
  * A File built over another File has no path, so every engine serialises it
- * through the blob route, which is also the route WebKit takes for a File it
- * never gave a path. That makes this wrapper correct on every browser today and
- * after the upstream fix lands, whichever shape that fix takes. It references
- * the bytes rather than copying them, so it is safe for arbitrarily large files,
- * and it stays uploadable after the record it came from is rewritten or deleted.
+ * through the blob route instead. It references the bytes rather than copying
+ * them, so it is safe for arbitrarily large files.
  */
 export function uploadableFile(file: File): File {
   return new File([file], file.name, {

frontend/editor/src/proprietary/services/policyApi.test.ts

@@ -18,7 +18,7 @@ function sentForm(): FormData {
   return post.mock.calls.at(-1)?.[1] as FormData;
 }
 
-/** jsdom's Blob has no text(); FileReader is the one byte read it implements. */
+/** jsdom's Blob has no text(). */
 const textOf = (file: File) =>
   new Promise<string>((resolve, reject) => {
     const reader = new FileReader();
@@ -56,7 +56,6 @@ describe("runStoredPolicy", () => {
   });
 
   it("uploads a fresh File over the caller's bytes, never the caller's File object", async () => {
-    // A File restored from IndexedDB serialises as an empty body in WebKit; a wrapper does not.
     const source = document();
     await runStoredPolicy("policy-1", [source], "editor-file-1");
 

frontend/editor/src/proprietary/services/policyApi.ts

@@ -38,7 +38,6 @@ export async function runStoredPolicy(
   fileId?: string,
 ): Promise<string> {
   const form = new FormData();
-  // Wrapped: WebKit uploads a File restored from IndexedDB as an empty body.
   for (const file of files) form.append("fileInput", uploadableFile(file));
   if (fileId) form.append("fileId", fileId);
   // Don't set Content-Type: the HTTP client must generate multipart/form-data