[tomwangcn]

Summary

Fixes #684.

Each new Llama() calls the addon's setLogger, which released the previous logger's thread-safe function before installing the new one. The old function's deferred finalizer then ran and cleared the global "JS logger callback set" flag, so from the second getLlama() call on, native llama.cpp log lines no longer reached any custom logger and were printed by the addon's fallback to stdout/stderr instead.

Changes

• llama/addon/globals/addonLog.cpp: track the currently installed logger's context, install the new thread-safe function before releasing the previous one, and only clear the global callback flag when the finalized logger is still the current one. Single-instance behavior is unchanged.
• test/modelDependent/llama/logger.test.ts: new regression test that loads a model through two sequential getLlama() instances with separate loggers and asserts both receive native llama.cpp log lines (llama_model_loader). Without the fix, the second logger only receives the few TypeScript-side lines, so the test fails.

Verification

• Baseline (unpatched local build): first instance's logger receives 527 lines on model load; second instance's logger receives only 4 TypeScript-side lines while 44 native llama_model_loader lines leak to process stdout - matching the issue report.
• Patched build: both loggers receive 527 lines including all native lines, zero leaked to stdout.
• vitest run ./test/modelDependent/llama/logger.test.ts - passes (CPU build, NODE_LLAMA_CPP_GPU=false, bge-small-en-v1.5-q8_0.gguf).
• tsc --noEmit --project tsconfig.json - clean
• eslint on the changed files - clean

Tested on Linux x64 only; the change is platform-independent N-API ordering logic.