file viewer: hide the transcribe button

It calls POST /file-browser/transcribe, which refuses on every server here — no
STT endpoint is configured anywhere, so it is a control that can only fail. One
of those teaches people to distrust the controls beside it, and OCR and extract
audio sit right there.

Hidden rather than deleted. Speech-to-text is leaving the platform for a plugin,
and the wiring is the useful part: the handler, the loading state and the
sibling-markdown behaviour in FileViewerProvider are all still correct, so when
the plugin exists this becomes a call to it rather than a rediscovery.

It may not come back here at all — the other route to the same job is the file
browser's context menu, which a plugin reaches with a task, and that needs no
button in this header. The comment says so, so whoever finds `false &&` knows it
is a decision rather than debugging left behind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

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

@@ -98,7 +98,22 @@ export const FileViewerHeader = () => {
           {ocrLoading ? <Loader2 className="h-3.5 w-3.5 animate-spin" /> : <ScanText className="h-3.5 w-3.5" />}
         </button>
       )}
-      {fileType === 'audio' && (
+      {/*
+        TRANSCRIBE — hidden, not deleted, and the distinction is deliberate.
+
+        Speech-to-text is leaving the platform for a plugin of its own. Until that lands this button calls
+        `POST /file-browser/transcribe`, which refuses on every server here because no STT endpoint is
+        configured anywhere — so it is a control that can only fail, and one of those teaches people to
+        distrust the controls beside it.
+
+        Kept because the wiring is the useful part. When the plugin exists this becomes a call to it, and
+        the handler, the loading state and the sibling-markdown behaviour in FileViewerProvider are all
+        still correct; deleting would mean rediscovering them.
+
+        It may not come back here at all. The other route to the same job is the file browser's context
+        menu, which a plugin reaches with a task — and that path needs no button in this header.
+      */}
+      {false && fileType === 'audio' && (
         <button
           onClick={handleTranscribe}
           disabled={transcribeLoading}