fix(client): downloads stream to disk, and two rough edges on first run

**Downloads were going through RAM.** `_openDownloadTarget` tries a granted
folder, then a service worker, then its floor: collect the whole file in the
page and hand the browser a blob. Both of the first two are absent in the
desktop application — `showDirectoryPicker` does not exist, and Chromium refuses
a service worker on a custom scheme — so every download under 512 MB took the
floor. A gigabyte of film meant a gigabyte of RAM, and the only visible symptom
was a Save As dialog at the *end* rather than the start, which is what the
operator noticed and asked about.

The main process now streams to disk: it honours "save automatically" with a
folder chosen once and no dialog, never overwrites (a colliding name gets a
suffix), awaits each write so the renderer cannot outrun the disk and queue the
file in memory anyway, and unlinks a cancelled download rather than leaving a
truncated file that looks complete to whoever opens it next. Settings now offers
the native folder picker instead of saying downloads are unsupported.

Measured in the running application: the file on disk grows 256 KB → 512 KB →
768 KB → 1 MB as the chunks arrive, and an aborted download leaves nothing
behind.

**A permanent scrollbar on sign-in.** `.layout` and `.page-center` each reserved
`100vh - 52px`, and `.page-center` sits inside `main`'s 24px vertical padding —
so the page overflowed by exactly 48px at every window size. Found by measuring
in the app rather than reading the stylesheet: `scrollHeight` 819 against a 771
viewport, then the bottom edge of every element. The centring page brings its
own padding, so main's is dropped for it and the duplicated arithmetic goes
rather than growing a third term. Now `scrollHeight == innerHeight`, no
overflowing elements.

**The first-run screen was unstyled.** It used a class name I invented
(`auth-page`) that appears nowhere in the stylesheet, so it had no card and the
button sat against the input. It now uses the same `page-center` + `login-card`
markup as sign-in, which is where the 12px gap comes from. The sign-in link in
the nav is hidden until a hub is chosen — it led to a page that could not work.

809 tests pass.

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

1 files changed, 15 insertions, 4 deletions

diff --git a/packages/meshbay-client/src/preload.js b/packages/meshbay-client/src/preload.js
index b649ae3..caad523 100644
--- a/packages/meshbay-client/src/preload.js
+++ b/packages/meshbay-client/src/preload.js
@@ -66,15 +66,26 @@ contextBridge.exposeInMainWorld('meshbay', {
     backend: () => ipcRenderer.invoke('secrets:backend'),
   },
 
-  // A save dialog and a write that never passes back through the page. The
-  // renderer holds an id, not a path.
-  saveFile: async (suggestedName) => {
-    const handle = await ipcRenderer.invoke('save:begin', suggestedName);
+  // Where downloads go, chosen once. The renderer never sees or sends a path —
+  // it asks for a dialog and is told the folder's name for display only.
+  folder: {
+    choose: () => ipcRenderer.invoke('folder:choose'),
+    get: () => ipcRenderer.invoke('folder:get'),
+    forget: () => ipcRenderer.invoke('folder:forget'),
+  },
+
+  // A sink that writes to disk as chunks arrive, never a buffer handed over at
+  // the end. `auto` uses the remembered folder without a dialog, which is what
+  // "save automatically" means; without one, or when the person asked to be
+  // prompted, a dialog opens. The renderer holds an id, not a path.
+  saveFile: async (suggestedName, opts) => {
+    const handle = await ipcRenderer.invoke('save:begin', suggestedName, opts);
     if (!handle) return null;
     return {
       name: handle.name,
       write: (chunk) => ipcRenderer.invoke('save:write', handle.id, chunk),
       close: () => ipcRenderer.invoke('save:end', handle.id),
+      abort: () => ipcRenderer.invoke('save:abort', handle.id),
     };
   },
 });