fix: the notification event function is the main thread's environment's, made once

[sidorares]

The bug

src/notifications.mm's ProbeCenter() made the process-wide response
threadsafe function gEvents in whichever environment first loaded the
module, behind a plain bool gProbed. Its callback CallJsEvent runs on
that environment's thread, and hands the response to EmitOrHold →
CALEmit, which in pump mode (channel not open) delivers only when
pthread_main_np() is true.

So if a Worker got to the addon first:

• every notification response afterwards crossed to the worker's thread and
  was silently dropped there — with the main thread's
  setBackendEventCallback() listener installed the whole time;
• once that worker ended, CALTsfn marked the function unusable and
  responses were dropped for good;
• gHeld, the hold-and-replay list, is the main thread's (pump2 reads it),
  so the worker's EmitOrHold was also writing a std::vector the main
  thread reads unsynchronised;
• gProbed itself was an unsynchronised bool read and written from any JS
  thread.

The fix

The event function is now the main thread's environment's, made the once —
the same shape InitCalendars already uses for the EventKit store's change
function (#68):

static std::atomic<CALTsfn*> gEvents{nullptr};
...
if (pthread_main_np() && !gEvents.load()) { ... }

QueueEvent drops a response while it is null: the main thread has not
loaded the module, so nothing there could be listening either.

The centre itself is unchanged in behaviour — NSBundle,
+currentNotificationCenter and the delegate are the process's and still go
up at the first load whichever environment's it is, because the delegate has
to be in place before initApp()'s finishLaunching. Its guard is now a
std::once_flag, which also publishes gCenter / gUnavailable /
gCategories to every later loader's thread; a verb only ever runs in an
environment that has loaded the module, so its read of gCenter is behind
that call_once.

Test

New test/notifications.js, driving the postNotificationResponse seam
(which needs no app bundle — nothing there touches the centre):

1. a Worker loads the addon and posts a response before the main thread
   has required it at all, and is gone again;
2. only then does the main thread require('..'), hold two responses with no
   listener, install one, and get them replayed in arrival order;
3. then one event per response, userInfo round-tripped through JSON,
   userText, an absent actionId reading as 'default', and no duplicates.

It also covers the argument shapes (9 bad ones, each a TypeError naming the
verb) and the capability readback — including that the posting verbs throw
naming the reason in a bare node rather than dropping silently.

Against the previous build it fails deterministically at step 2:

notifications: the responses from before the listener should replay []

Registered in npm test and in CI, between screencolor.js and
threaded.js.

Verified

• npm run build — clean, no warnings
• npm test — exit 0, whole suite, screen unlocked (the GUI tests included)

One flaky-under-load note: test/threaded.js's round-trip assertion
(p95 < 2 ms locally) tripped at 6.4 ms when run immediately after a full
node-gyp rebuild; on an idle machine it is p95 ≈ 0.11 ms over five runs.
Not related to this change — that path touches no notification code.

No issue was filed for this; found by inspection of the notifications face
(originally #26).