fix: restore a saved undefined process.exitCode as an explicit 0

[AntonOfTheWoods]

PGlite saves and restores process.exitCode around engine calls that may run proc_exit(XX) (#init(), close(), execProtocolRaw). On a clean host the saved value is undefined, and under bun assigning undefined to process.exitCode does not clear the current value — depending on the current value it is either a silent no-op or throws TypeError: exitCode must be an integer. The restore therefore fails, and the engine's proc_exit(99) boot sentinel survives to process exit: a fully successful bun process exits with code 99.

Until 0.5.4 this was masked by an accident: close()'s _emscripten_force_exit(0) set an explicit 0 on the way out. #1059 (correctly) made close() restore the previously saved value instead — which removed the incidental reset and exposed the bug for every bun consumer of the 0.5.5 release. Repro, run with bun against @electric-sql/pglite@0.5.5:

import { PGlite } from '@electric-sql/pglite'
const pg = await PGlite.create()
await pg.exec('SELECT 1')
await pg.close()
// prints nothing wrong — but the process exits 99

This also fails any downstream bun test suite that touches PGlite: every test passes and the runner still exits 99.

The fix routes all three restore sites through one helper that restores a saved undefined as an explicit 0, which is equivalent for exit status on every runtime. The added regression test asserts the boot sentinel never remains on process.exitCode; under bun the whole suite additionally force-exits 99 without the fix, so the lane goes red either way.

🤖 Generated with Claude Code

[AntonOfTheWoods]

#1087 supersedes this PR, and it fixes the underlying issue — happy to see this closed in its favor.

I verified empirically: built 6c14380 with its CI WASM artifacts and ran this PR's repro under bun. On the 0.5.5 release, process.exitCode is 99 after PGlite.create() and the process force-exits 99; on the #1087 build it is 0 throughout and the process exits 0. Keeping the exit status WASM-side instead of publishing it to the host is a better fix than repairing the JS-side restore (this PR's approach).

Two things surfaced while verifying that you may want to look at:

1. The new regression test in Improvements to exit code #1087 fails under bun. restores undefined process.exitCode on close does process.exitCode = undefined as setup, and under bun that assignment throws TypeError: exitCode must be an integer when exitCode is unset (bun also treats it as a silent no-op when a value is already present — the same runtime quirk that caused the original bug). The equivalent test in this PR avoids ever assigning undefined — it captures the pre-create value and asserts the sentinel never remains — which may be a useful shape if you want that test to run under bun.

2. The bun lane may not be running basic.test.ts at all: the test:bun script references tests/basic.test.js, but the file is tests/basic.test.ts — which would explain why the bun-incompatible test setup hasn't surfaced in CI.

Thanks for the quick fix!