… handlers

The Goose desktop app crashes with EXC_BREAKPOINT (SIGTRAP) / brk #0 on the
main thread (CrBrowserMain) approximately 29 minutes after launch.

Root cause: calling Buffer.toString() inside Node.js stream 'data' event
handlers on the Electron main thread triggers the following V8 code path:

  Buffer.toString('utf8')
  → node::StringBytes::Encode()
  → v8::String::NewFromUtf8()
  → V8 NEW_STRING macro → .ToHandleChecked()

When V8 cannot allocate a new string (GC pressure, near-OOM, or isolate
state during concurrent garbage collection), NewFromUtf8 returns an empty
MaybeLocal, and ToHandleChecked() hits a CHECK → FATAL → brk #0 →
EXC_BREAKPOINT (SIGTRAP).

This is triggered because libuv delivers stream data chunks via callbacks
on the main thread's event loop. Each data.toString() call forces an
immediate V8 heap allocation in the hot I/O path, competing with GC.

Fixes applied to three vulnerable code paths:

1. check-ollama handler (main.ts): Accumulate raw Buffer chunks in arrays
   during 'data' events, defer Buffer.concat().toString() to the 'close'
   handler after the stream has ended.

2. read-file handler (main.ts): Replace spawn('cat') + stream piping with
   fs.readFile() on all platforms. This returns a single Buffer after the
   read completes, avoiding per-chunk V8 string allocation entirely.

3. goosed process stdout/stderr (goosed.ts): Batch raw Buffer chunks and
   flush via setImmediate(), moving the toString() call out of the libuv
   I/O callback and into a subsequent event loop tick where V8 heap
   allocation is safer.

Crash signature from macOS crash report:
  Exception Type:  EXC_BREAKPOINT (SIGTRAP)
  Exception Codes: 0x0000000000000001, 0x0000000112b6cef0
  Thread 0 Crashed: CrBrowserMain
  0 Electron Framework  ares_dns_rr_get_ttl + 3711128
  ...
  29 node::StringBytes::Encode + 272
  30 node::Buffer::RegisterExternalReferences + 25908

Electron 40.4.0 / Node.js 24.x / V8 14.4.x / macOS ARM64

Signed-off-by: Jacob Szymik <[email protected]>