macOS hotkey: promote process to UIElement + run Carbon event loop (actually fire Cmd+;)

Root cause of Cmd+; still being dead after the v1 run-loop fix: the LaunchAgent
starts jcode as a faceless background process with no window-server connection,
so Carbon RegisterEventHotKey events are never delivered to it regardless of the
run loop. Pumping CFRunLoopRun() alone was necessary but not sufficient.

Fix:
- Call TransformProcessType(kProcessTransformToUIElementApplication) so the
  listener becomes a UIElement app (window-server connection, no Dock/menu-bar
  presence) and is eligible to receive global hotkeys.
- Replace the bare CFRunLoopRun() with RunApplicationEventLoop(), which installs
  the standard Carbon application event handlers that the hotkey event target is
  serviced by, and does not return spuriously when no CF input source is
  installed.
- Initialize logging and emit lifecycle diagnostics (start / promote status /
  registered / key pressed / launch failures) to both the jcode log and stderr
  (captured by the plist StandardOut/ErrorPath), so the listener is observable.
- Keep the GlobalHotKeyManager alive for the lifetime of the event loop.

Bump HOTKEY_LISTENER_VERSION to 2 so users already on the v1 listener get the
LaunchAgent reinstalled automatically on update. Add a test asserting every
prior listener version migrates.

Validated by compiling the extracted macOS module + listener for
aarch64-apple-darwin (only the macOS system linker is unavailable on this Linux
host; all Rust + FFI type-checks pass).