fix(android): drain JNI stdio pumps before returning from node::Start

[gmaclennan]

Summary

• Closes Android: fix JNI stdio pump drain race in NodeJSService #19
• Stop detaching the stdout/stderr pump threads in jni-bridge.cpp; close all four write-end refs (including STDOUT_FILENO/STDERR_FILENO dup2 aliases) so read() sees EOF, then pthread_join before closing the read ends. The pump buffer now drains before JNI returns from node::Start, so an uncaught-exception traceback can no longer be lost on teardown.

Test plan

• Trigger a crash in the embedded Node entrypoint and confirm the stderr traceback appears in logcat instead of __NODE_EXIT__:1 with no preceding error
• Normal startup/shutdown still works end-to-end on Android (no hang in pthread_join)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes an Android teardown race where stdout/stderr pump threads could be terminated before draining the pipe buffer, causing Node.js crash tracebacks (notably uncaught exceptions) to be lost from logcat.

Changes:

• Stops detaching the stdout/stderr pump threads so they can be joined deterministically.
• Closes the write-end file descriptors (including STDOUT_FILENO/STDERR_FILENO dup2 aliases) to force EOF and allow pump threads to drain before JNI returns.
• Joins pump threads before closing read ends.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gmaclennan]

Doesn't apply to this codebase: startNodeWithArguments is invoked exactly once per OS process, so the fd-1/2 reuse path can't be reached.

• NodeJSService.start() rejects any state other than STOPPED, and ERROR is per-instance terminal — recovery is destroy() + new instance, not a second start() on the same instance (NodeJSService.kt:96-102, start guard at :353-359).
• The Node thread runs in the :ComapeoCore foreground-service process. Stop kills that process, and the Android service framework launches a fresh process for the next start (the instrumented test does an explicit kill on the FGS pid for the same reason).
• Independently, nodejs-mobile's node::Start() is one-shot — it can't be called twice in the same process.

So fds 1/2 are only ever closed at JNI return, immediately before the process exits. There's no second pipe()/dup2() to race with.

[gmaclennan]

Validated and fixed in b3311e2 — track creation success per pump and only pthread_join the threads that were actually started, so a pthread_create failure no longer leads to UB on the uninitialized pthread_t.

Note on the partial-init flag (first pthread_create succeeds, second fails, dup2'd stderr has no pump): kept as-is. It's pre-existing behavior — the previous detached-thread version had the same dup2-without-pump exposure on pthread_create failure — and given how rare pthread_create failures are on this device class, "stdout/stderr writes may block until OOM-kill" felt like a niche enough corner to leave alone rather than refactor start_redirecting_stdout_stderr for full atomic rollback.