Document display proxied through the backend; profile fetches parallelized
Two follow-up fixes after the Case.dev migration. The `GET /single-documents/:id/display` route stopped issuing a 302 redirect to a Case Vault signed URL and now proxies the bytes through the backend. Profile data for the Account > Models page shifted from sequential awaits to `Promise.all`, eliminating a false "missing key" flash on load.
The display route previously redirected the browser to a presigned Case Vault URL. Production was returning "Failed to load document" because the frontend fetch was chasing a cross-origin URL. The fix calls downloadFile() server-side, buffers the bytes, sets Content-Type (PDF, DOC, or DOCX), Content-Disposition: inline, and Cache-Control: private, no-store, then sends the buffer. The browser never sees a Case.dev URL or holds a signed link in history.
The authorization tradeoff is explicit in the README: the backend is the auth boundary, the browser never calls Case.dev directly. Proxying the bytes enforces that. The cost is backend bandwidth; for document previews at low-to-moderate volume that's usually acceptable.
The profile load fix is straightforward. Five calls -- getCaseApiKeyStatus, getCaseModelCatalog, getDemoUsage, getProviderCredentialStatuses, and getUserProfile -- were previously awaited one after another. Wrapping them in Promise.all cuts round-trip time from the sum of the five calls to the slowest one. A Loader2 spinner replaces the false "missing key" UI while loading is true.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?