fix(vrowzer): write binary files given to ready() as bytes in both Workers

[kazupon]

Closes #65

Binary files (ArrayBuffers) passed to ready({ files }) are now written with their bytes in both Workers, instead of as the string [object ArrayBuffer].

Cause

initialize() treated config.files as Record<string, string> and sent the files as text:

• The Web Worker received them in the files of V_WW_SETUP, and updateFile() wrote every value with { encoding: 'utf8' }.
• The Service Worker received them in the text field files of V_FS_INIT, which the @vrowzer/fs subscriber writes as UTF-8. The binary field, binaryFiles, was not used.

Binary files added later with addFile() or updateFile() were not affected.

Fix

• Service Worker: initialize() splits the files into text and binary, and sends the binary files in binaryFiles of V_FS_INIT. The subscriber already writes them as bytes and emits add events, so public images also enter the public file list (fix(vite-dev-server): serve public files given to the runtime from the Service Worker #64). @vrowzer/fs is unchanged. With text files only, the message is the same as before.
• Web Worker: updateFile() writes an ArrayBuffer as bytes, as the subscriber does, and a string as UTF-8 text as before. SetupWorkerMessage.files, setupWorker() and updateFile() accept ArrayBuffer values. The types are only widened, so existing callers keep working.
• Copies: ready() copies the files when it is called, ArrayBuffers included, and sends the copies without a transfer list. Each Worker receives its own copy through structured cloning, and the caller's buffers stay usable, as with addFile() since feat(vrowzer): resolve file operations after the Workers apply them #61.
• The JSDoc of VrowzerConfig.files and the README section of ready() describe the copy. The API references are regenerated.

FileSystemPublisher.initFiles() is not used. It would also send the files to the Web Worker, which already loaded them during setup, and it has its own bug (#63).

Behavior change

ready() now sends the files as they were when it was called. Before, it read config.files later, after loading the client files, and each Worker received the ArrayBuffers as they were when its message was sent. So changes that the caller made while ready() ran could reach one Worker and not the other, and an ArrayBuffer that the caller detached in the meantime could make ready() fail.

This keeps one extra copy of each binary file in memory until ready() finishes.

Not included

• FileSystemPublisher.initFiles() (Copy binary files for each target in FileSystemPublisher.initFiles() #63): it still transfers the caller's buffers to every target. The JSDoc of FSInitMessage, which says that binaryFiles are transferred, will be updated there.
• Values outside the type, such as numbers, Blobs or typed arrays: they are not validated, as with addFile().
• Service Worker restarts (Recover project files and channels after Service Worker process restart #46): the files given to ready(), text or binary, are lost when the Service Worker restarts.
• Debug logging in the Service Worker middlewares.

Tests

• Unit tests:

  • transformer.test.ts: updateFile() and the initial files of setupWorker() write an ArrayBuffer as bytes and a string as UTF-8 text. Both tests failed before the change.

  • index-file-sync.test.ts:

    • binary files reach both Workers as copies with the same bytes, in the files of V_WW_SETUP and in the binaryFiles of V_FS_INIT, without a transfer list, and the caller's buffer keeps its bytes;
    • changes made right after calling ready(), to an ArrayBuffer or to the file record, do not reach the Workers.

    Both tests failed before the change, and fail again without the copy in ready(). The existing test of text-only initialization passes unchanged.

• Integration tests in the shared playground, which now passes a public image and a binary file outside the public directory to ready():

  • the Service Worker serves both with the same bytes, through servePublicMiddleware and serveStaticMiddleware;
  • the Web Worker inlines the same bytes with ?import&inline;
  • the caller's ArrayBuffers keep their size and content after ready().

  Reverting either fix makes the matching test fail with the bytes of [object ArrayBuffer]. This also confirms in the browser that both Workers were affected.

Validated locally with:

• vp run test:unit: 119 files, 1,911 tests
• vp run test:integration:vrowzer: 67 passed and 1 conditional skip, in three runs
• vp run test:e2e: 46 passed, 6 existing test.skip
• oxlint (no new warnings), knip, the format check of the changed files, and typecheck