[bug]: App crashes when the Mac wakes from sleep

[dgarros]

Bug Description

emdash has crashed multiple times (the main app window disappears / the process is gone)
when my Mac wakes up from sleep. It doesn't happen on every sleep/wake cycle, but it has
recurred more than once. The app has to be relaunched when it happens.

I've seen this on two different versions (1.1.34 and 1.1.35), so it doesn't appear to be
specific to a single build.

Steps to Reproduce

1. Launch emdash and leave it running (in my case with at least one workspace open,
   including a remote/SSH-backed repository).
2. Let the Mac go to sleep (close the lid or let it idle into sleep).
3. Wake the Mac back up.
4. Some of the time, emdash has crashed and is no longer running. (It doesn't reproduce
   on every wake — I've had wakes where the app survived — but it has happened more than
   once.)

Actual vs Expected Behavior

Actual: On wake, the emdash process terminates abnormally. macOS records a crash
report for it. The crash is an abort (SIGABRT) on the main process.

Expected: emdash keeps running across a sleep/wake cycle.

The macOS crash report shows the abort happening in the bundled native file-watcher
module (@parcel/watcher) as it delivers a callback while the Node/Electron environment
is shutting down. Sanitized top of the crashing thread (CrBrowserMain):

abort
node::OnFatalError(char const*, char const*)
napi_fatal_error
watcher.node  (callbackEventsToJS / Napi::ThreadSafeFunction::CallJS)
... uv__work_done / uv_run ...
node::Environment::CleanupHandles()
node::Environment::RunCleanup()
node::FreeEnvironment(node::Environment*)

At the same instant as the crash, the app log also records network sockets being reset
and an unhandled Error: SSH connection is not available (the last thing logged before
the process dies). I don't know whether that's related to the crash or just a side effect
of the network dropping on sleep.

emdash Version

1.1.35 (also reproduced on 1.1.34)

Operating System

macOS 26.5.1 (build 25F80), Apple Silicon

Additional Context

I confirmed the crash time lines up exactly (to the second) with a system wake event in
the macOS power log, across multiple occurrences.

Hypothesis (for you to verify — I haven't confirmed root cause): it looks like a
pending @parcel/watcher thread-safe-function callback is being delivered during
environment teardown on wake, which triggers the fatal N-API error and the abort. It may
be worth checking how file watchers are torn down / re-subscribed across a sleep/wake
cycle on macOS (e.g. via Electron's powerMonitor resume), but I'll leave the actual
diagnosis to you.

Bundled watcher version observed in the app bundle: @parcel/watcher 2.5.6
(darwin-arm64 backend).

I have the full macOS .ips crash reports (two of them) and the surrounding app-log and
power-log excerpts. They contain some machine-identifying details so I didn't paste them
here — happy to share them privately or attach scrubbed copies if that would help.