say WHY a file could not be opened, and offer the thing that still works

Opening a large text file showed "Failed to read file" and nothing else. The
server had already said exactly what was wrong — "File too large to read
(max 5 MB)" — and the viewer threw it away: `.catch(() => setError('Failed to
read file'))` ignored its argument.

`hono.ts:297` renders a CustomError as `ctx.text(error.message)`, so that sentence
arrives verbatim as `ApiError.message`. It is shown now.

Guarded rather than trusted, because error paths are where surprises live. A body
is only displayed when it looks like prose: an HTML page from a proxy, a JSON
envelope from a route that sets `returnValue`, an empty string or something
300 characters long all fall back to the generic line. Checked all seven cases.

The error state also stopped being a dead end. Being told a file is too big, with
nothing to do about it, leaves the reader stuck — but the bytes are still there
and only the UTF-8 READ is capped; `/raw` has no limit. So it offers "Download
instead", which is the action that still works.

This is the same class as the empty-file bug found earlier today: the viewer knew
the answer and did not pass it on.

tsgo clean, frontend builds, 817 pass / 7 fail unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/workspaces/officerdev/src/apps/FileViewer/FileViewerBody.tsx

@@ -1,5 +1,5 @@
 import { useMemo, useRef } from 'react';
-import { Loader2, FolderArchive } from 'lucide-react';
+import { Loader2, FolderArchive, FileWarning, Download } from 'lucide-react';
 import { getLang, getRawUrl, getArchiveBaseName } from './file-types';
 import { useFileViewer } from './FileViewerContext';
 import { PdfRenderer } from './renderers/PdfRenderer';
@@ -14,7 +14,7 @@ import { EditorRenderer } from './renderers/EditorRenderer';
 import { JsonEditorRenderer } from './renderers/JsonEditorRenderer';
 
 export const FileViewerBody = () => {
-  const { filePath, fileName, root, fileType, content, loading, error, autoPlay, editing, setContent } =
+  const { filePath, fileName, root, fileType, content, loading, error, autoPlay, editing, setContent, handleDownload } =
     useFileViewer();
   const scrollRef = useRef<HTMLDivElement>(null);
 
@@ -38,8 +38,19 @@ export const FileViewerBody = () => {
           <Loader2 className="h-6 w-6 text-duck-teal animate-spin" />
         </div>
       ) : error ? (
-        <div className="flex items-center justify-center h-full">
+        // Being told a file is too big to open, with nothing to do about it, is a dead end. The bytes are
+        // still there and `/raw` has no size limit — only the UTF-8 read does — so downloading is the
+        // action that still works, and it is offered rather than left to be guessed at.
+        <div className="flex flex-col items-center justify-center h-full gap-3 px-6 text-center">
+          <FileWarning className="h-8 w-8 text-duck-dark/30" />
           <span className="text-sm text-red-500">{error}</span>
+          <button
+            onClick={handleDownload}
+            className="inline-flex items-center gap-1.5 rounded-md border border-duck-dark/20 px-3 py-1.5 text-xs text-duck-dark transition-colors hover:bg-duck-dark/5 cursor-pointer"
+          >
+            <Download className="h-3.5 w-3.5" />
+            Download instead
+          </button>
         </div>
       ) : fileType === 'pdf' ? (
         <PdfRenderer src={getRawUrl(filePath, root)} />

src/workspaces/officerdev/src/apps/FileViewer/FileViewerProvider.tsx

@@ -17,6 +17,27 @@ type FileViewerProviderProps = {
   children: ReactNode;
 };
 
+/**
+ * The server's own sentence, when it is fit to show.
+ *
+ * `hono.ts` renders a CustomError as `ctx.text(error.message)`, so "File too large to read (max 5 MB)"
+ * and "Cannot read a directory" arrive verbatim — and every one of them used to be thrown away for a flat
+ * "Failed to read file", which tells the reader nothing and sends them looking for a bug that is not
+ * there.
+ *
+ * Guarded rather than trusted: a body is only shown when it looks like prose. An HTML error page from a
+ * proxy, or a JSON envelope from a route that sets `returnValue`, would otherwise be rendered raw at the
+ * user — worse than the generic line it replaced.
+ */
+function readableError(err: unknown): string {
+  const generic = 'Failed to read file';
+  if (!(err instanceof Error) || !err.message) return generic;
+  const message = err.message.trim();
+  if (!message || message.length > 200) return generic;
+  if (message.startsWith('<') || message.startsWith('{') || message.startsWith('[')) return generic;
+  return message;
+}
+
 export const FileViewerProvider = ({
   filePath,
   fileName,
@@ -49,7 +70,13 @@ export const FileViewerProvider = ({
       return;
     }
 
-    if (fileType === 'audio' || fileType === 'video' || fileType === 'image' || fileType === 'pdf' || fileType === 'archive') {
+    if (
+      fileType === 'audio' ||
+      fileType === 'video' ||
+      fileType === 'image' ||
+      fileType === 'pdf' ||
+      fileType === 'archive'
+    ) {
       setLoading(false);
       return;
     }
@@ -59,7 +86,7 @@ export const FileViewerProvider = ({
     files
       .readFile(filePath)
       .then((res) => setContent(res.content))
-      .catch(() => setError('Failed to read file'))
+      .catch((err) => setError(readableError(err)))
       .finally(() => setLoading(false));
   }, [filePath, directContent]);