feat(gl-sdk): add log + node-event listener callbacks

[angelix]

Two callback-based listener APIs for mobile integrators, both
following the Breez SDK shape.

Logging

• LogListener: apps implement on_log(LogEntry) to receive log messages
  from both gl-sdk (via tracing's log bridge) and gl-client (111
  log::*! callsites flow through automatically).
• LogEntry carries level, message, target module, and source file + line
  for easier triage of production issues.
• LogLevel variants use Rust PascalCase (Error/Warn/Info/Debug/Trace)
  matching the ChannelState/OutputStatus/PaymentStatus convention;
  bindings still render as UPPER_SNAKE per uniffi convention.
• set_logger(level, listener) returns Result<(), Error>. First call
  installs; subsequent calls are silent no-ops. Returns an error only
  when another crate has already installed a log logger, replacing the
  previous .expect("logger already set") panic.
• Exposed to JS via a NAPI wrapper that bridges a ThreadsafeFunction to
  LogListener (napi4 feature enabled).

Node events

• NodeEventListener: apps implement on_event(NodeEvent) to receive live
  events (InvoicePaid today; room for more).
• Replaces the pull-based NodeEventStream + next() surface entirely.
  NodeEventStream is gone.
• Listener is strictly a connect-time concern:
  register / recover / connect / register_or_recover each gain an
  event_listener: Option<Box> parameter. The
  SDK installs it atomically during node bring-up, so events that fire
  during the first round of RPCs are not missed.
• set_event_listener is pub(crate) — not exposed via uniffi or NAPI.
  Callers who need post-construction flexibility wire a mutable delegate
  inside their listener implementation (Flow/LiveData/ObservableObject
  pattern). Matches Breez's EventListener shape.
• Single listener per Node. Drop for Node aborts the dispatch task so
  teardown is automatic.

Tests

• Python test_logging.py asserts the logging types exist and set_logger
  accepts a listener.
• Kotlin LoggingTest.kt installs a listener and drives register_or_recover
  as a smoke test for cross-language log capture.

[cdecker]

I'm not quite happy with encumbering what is supposed to be the simple interface (naked top-level functions) with things like logging and event subscriber handling. That's more advanced concerns and exactly a problem of naked functions: they have no context other than the global static context they could be configured, hence all possible variants must be expressible in the argument list, which adds complexity back in.

I'd say if you use the simple interface you do not get to play with these advanced features, if you want those you have to use the OOP interface, where we can use builders to incrementally expose details. That is also in tune with the semver logic: naked functions change their entire interface when you add optional arguments, whereas builders can add new setters without breaking existing code.

Can we split out the log handling, which I'd merge right away, and keep the event streaming discussion separate?

[cdecker]

Not quite sure if Once is the right type here. It should be a Mutex<LogListener>, since otherwise multiple set_logger calls are ignored, which I don't think anybody expects.