fix: exit codes were 127 on any receipt path that touched I/O

[dkitchell]

The bug

The entry point called process.exit(code), which tears the process down immediately. On Windows, if a libuv async handle is mid-close when that happens — which it is on any path that did fs or network I/O — Node aborts:

Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76

The verdict is printed before that, so output looked correct while the shell saw 127 instead of the documented code:

invocation	actual	documented
valid local receipt file	127	0
tampered receipt	127	1
malformed receipt	127	3
--version	0	0
bare UUID (network only)	0	0

CI consumers are the one audience that reads the exit code rather than the text, so this broke precisely the users the codes exist for. The README publishes them as a contract.

The fix

Assign process.exitCode and let the event loop drain, instead of forcing exit. Node then closes its handles and exits normally with the requested code. All five paths verified by hand:

version           -> 0 (expect 0)
valid local file  -> 0 (expect 0)
tampered          -> 1 (expect 1)
malformed         -> 3 (expect 3)
network uuid      -> 0 (expect 0)
libuv assertion   -> none

Why nothing caught it

The existing CLI tests exercise the certificate path with --offline, which never opens a socket and so never hits the race. src/exit-codes.test.ts covers the receipt path — including a local-file read that still fetches the public key, the exact combination that aborted — and asserts both the code and the absence of an abort, so a regression cannot hide behind correct-looking stdout.

65 tests pass, up from 59.

Relationship to the npx 127

This is a different 127 from the npx github: failure fixed in #4. That one was bin resolution — nothing ran. This one runs, prints the right answer, and then dies. They share an exit code and nothing else; both needed fixing.

🤖 Generated with Claude Code