fix(emulator): stringify send() errors before writing them to stderr

[mattsears18]

Description

Fixes #10876.

EmulatorLog.flush() handed the Error object from process.send()'s callback straight to process.stderr.write():

(process.send as any)(nextMsg, undefined, {}, (err: any) => {
  if (err) {
    process.stderr.write(err);   // err is an Error object
  }
  ...
});

stream.write() accepts only a string, Buffer, TypedArray, or DataView, so writing an Error throws synchronously — inside a callback with no surrounding try/catch, which makes it an uncaught exception:

TypeError: The "chunk" argument must be of type string or an instance of Buffer, TypedArray, or DataView. Received an instance of Error
  at _write (node:internal/streams/writable:480)
  at lib/emulator/types.js:180

That path only runs when the IPC channel to the functions runtime has already failed (the subprocess died, was killed, or the channel closed), so the error being destroyed is exactly the one explaining why the runtime became unreachable. Operators are left with a TypeError about stream chunk types pointing at Node's stream internals instead. We hit this on CI runners where the emulator subprocess gets killed under memory pressure, and it made two separate emulator-flake investigations materially harder.

This stringifies the error before writing, using the existing getErrStack() helper from src/error.ts so a non-Error value is handled too:

process.stderr.write(`${getErrStack(err)}\n`);

Behavior is otherwise unchanged — same call site, same flush loop, same buffering semantics.

Scenarios Tested

Added src/emulator/types.spec.ts covering the flush() error path. Its process.stderr.write stub enforces Node's real chunk-type restriction, so the test reproduces the actual crash rather than just asserting on the argument:

• process.send() reports an Error → the stack is written to stderr, no throw. Fails on main with the exact TypeError from the issue; passes with this change.
• process.send() reports a non-Error (e.g. a string code) → written as-is, no throw.
• process.send() succeeds → nothing written to stderr.

Verification run locally on Node v24.15.0:

• mocha src/emulator/*.spec.ts → 143 passing.
• Full unit suite (mocha 'src/**/*.spec.{ts,js}') → 4954 passing, 10 pending, 2 failing. Both failures are unrelated to this change and reproduce on unmodified main: src/commands/login.spec.ts ("authCode completion flow") fails identically on a pristine checkout, and the accounts:update auth-emulator failure is a socket hang up under full-suite load — that spec file passes 46/46 in isolation both with and without this change.
• tsc --project tsconfig.compile.json → clean.
• eslint on both touched files → no errors; prettier --check → clean.

Sample Commands

No command or flag surface changes.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request fixes an issue in the Functions emulator where an IPC failure was masked by a TypeError when writing the raw error object to process.stderr. It introduces unit tests for EmulatorLog.flush() and uses getErrStack to safely log the error stack. The review feedback suggests avoiding the 'as any' cast on process.send by using a specific function signature to align with the repository style guide, and clearing EmulatorLog.LOG_BUFFER upon encountering an IPC error to prevent flooding stderr with duplicate stack traces.