fix(ruvocal): faithful RvfGridFSBucket GridFS shim + allow wasm: scheme in isValidUrl

[clawdia-ai-assistant]

Summary

Two independent fixes to the RVF-backed ChatUI (ruvocal), both currently carried as out-of-tree patches in our deployment. They're unrelated and a reviewer can take either on its own; happy to split into two PRs if you'd prefer.

1. RvfGridFSBucket is an incomplete GridFS shim → file upload/download/fork all 500

src/lib/server/database.ts hardcodes the RVF backend (new RvfGridFSBucket()), and that class is a shim mimicking MongoDB's GridFSBucket so the chat-ui file callers keep compiling. The mimicry is incomplete in three ways, and every Mongo-era caller breaks at runtime:

1. openUploadStream was not a Writable — it returned { id, write, end }. files/uploadFile.ts does upload.once("finish"/"error", …) → TypeError: upload.once is not a function → HTTP 500 on every attachment upload.
2. Silent corruption — uploadFile.ts passes an ArrayBuffer (cast to Buffer). The old write() did chunk.toString("base64") on it, persisting the literal string "[object ArrayBuffer]". (A naïve default-mode Writable would instead throw ERR_INVALID_ARG_TYPE on the ArrayBuffer.)
3. openDownloadStream was not a Readable, find() was mis-shaped — openDownloadStream returned { toArray } (no .on/.pipe); find() was async returning { toArray } with no .next(). files/downloadFile.ts and routes/conversation (copy-on-fork) call these as real streams/cursors without awaiting find, so reading a file back and forking a shared conversation with attachments each 500 independently.

(2) and (3) were latent because those paths only run once files exist, and uploads never succeeded — so fixing only openUploadStream surfaces the next crash rather than working.

Fix (one file, zero caller changes):

• openUploadStream returns a real objectMode Writable that coerces each chunk via Buffer.from (absorbs ArrayBuffer/Uint8Array/Buffer/string), persists on final, and carries .id — so .once("finish"), .write(), .end(), and .pipe() all work.
• openDownloadStream returns a real Readable via Readable.from.
• find() is synchronous and returns a cursor exposing both next() and toArray().

Storage stays base64 (download decodes → downloadFile re-encodes for its {type:"base64"} return; round-trip preserved). Verified end-to-end against a live deployment: ArrayBuffer upload → finish → byte-exact base64 round-trip → .pipe() copy-on-fork, plus an HTTP multipart upload + downloadFile() read-back.

2. isValidUrl rejects the wasm: scheme → browser-local MCP silently soft-bricks autopilot

ruvocal advertises an in-browser WASM MCP server ("RVAgent Local") to clients as url: "wasm://local", and the SPA selects it by default when no other MCP is configured. On every chat submit the server runs each selected MCP URL through isValidUrl(), which only permits http/https against safe hostnames — correct SSRF prevention for HTTP MCPs, but wrong for a scheme the server never fetches (the browser hosts the module). wasm://local is rejected, runMcpFlow strips it, sees zero valid servers, returns "not_applicable"; with autopilot ON the client then silently refuses to fire the POST — pick a model, type, hit send, nothing happens, no 4xx/5xx, no toast.

Fix: early-return true for url.protocol === "wasm:". HTTP/HTTPS SSRF checks unchanged.

Test plan

• Attach an image in the ChatUI with a multimodal model → response, no 500, no upload.once/ERR_INVALID_ARG_TYPE in the server log; re-open the conversation and confirm the image renders (exercises the read path).
• Fork/continue from a shared conversation that has a file attachment (exercises the .pipe() copy path).
• With only the WASM MCP selected + autopilot on, a chat submit no longer silently no-ops; no rejected … wasm / all selected MCP servers rejected warnings.

Existing test compatibility

The repo's src/lib/server/database/__tests__/rvf.spec.ts RvfGridFSBucket block passes unchanged on Node 22:

• upload and download — openUploadStream is now a real Writable; await stream.end() settles before the subsequent openDownloadStream(...).toArray().
• delete file — openDownloadStream on a missing file surfaces a "File not found" error on the stream (GridFS semantics, as the prior shim did via toArray()), so .rejects.toThrow("File not found") still holds. (It does not silently return an empty stream.)