Download endpoints return presigned S3 URLs instead of streaming bytes through Lambda

The three affected routes (GET /:documentId/docx, GET /:documentId/display, GET /download) previously called downloadFile() to pull bytes from S3 into Lambda memory, then wrote them to the response buffer. Each now calls getSignedUrl() with a 900-second TTL and returns a small JSON payload - { url, filename } or { url, type, filename } depending on the endpoint.

The frontend changes follow the same pattern across all call sites. useFetchDocxBytes, useFetchSingleDoc, DocDownloadBlock, and the DocPanel download button all do a two-step fetch: first hit the authenticated API endpoint to get the presigned URL, then fetch the actual bytes directly from S3 using that URL (no auth header needed - the presigned URL carries its own credentials). For DocDownloadBlock and the DocPanel button, a hidden <a> element is created with href set to the presigned URL and .click() triggered programmatically. The URL.createObjectURL / URL.revokeObjectURL pattern for blobs is gone.

One unrelated fix ships alongside: storage.ts was reading process.env.S3_BUCKET_NAME but CDK injects the bucket name as DOCS_BUCKET_NAME. That mismatch would have caused every download to fail before this was caught.

The display endpoint also changes its response shape slightly. It now returns { url, type, filename } where type is "pdf" if a PDF rendition is available for a DOCX, or the raw file_type otherwise. The frontend uses type === "pdf" to decide whether to pipe the S3 response to PDF.js or fall back to the docx-preview viewer.