QVAC-18793: split LlamaFinetuner out of LlamaModel

[jpgaribotti]

🎯 What problem does this PR solve?

• LlamaModel had grown to own both the inference path and the entire LoRA finetune pipeline (pause/resume checkpoint state, training loop, dataset prep, optimizer/scheduler), which made lifetime and locking hard to reason about.
• Finetune-only members (checkpointStateMutex_, currentCheckpointState_, pausedCheckpointState_) and ~20 private helpers cluttered LlamaModel.hpp even though they're only relevant on the finetune path.
• A latent deprecation warning from llama_adapter_lora_free (deprecated in current llama.cpp: "adapters are now freed together with the associated model") was building noise into compiles.

📝 How does it solve it?

• Introduces a dedicated LlamaFinetuner class that owns the finetune pipeline and pause/resume state. The class holds a reference back to its owning LlamaModel (composition; lifetime guaranteed by member ordering — declared last so it's destroyed first).
• LlamaModel exposes the finetuner via finetuner() accessors; process() delegates the finetune dispatch to finetuner_.finetune(...). friend class LlamaFinetuner lets the new class access the bits of LlamaModel it still needs (stateMtx_, state_, metadata_, reload(), getContext(), getModel()) — intended to be removed once those access points get small accessor helpers.
• FinetuneTerminalResult and the ProgressCallback alias move with the implementation. FinetuneConfigOverrides stays on LlamaModel because reload() / tuneConfigMap() on the inference path consume it.
• Pure move otherwise: method bodies, locking, and the STANDALONE_TEST_BUILD guards are preserved.
• Drops the now-deprecated llama_adapter_lora_free deleter on the resume path. Adapters are tied to model lifetime in current llama.cpp, and the surrounding reload(FinetuneConfigOverrides{}) calls on both the happy and error paths destroy + rebuild the model.
• AddonJs.hpp updated to call through llamaModel->finetuner().{isFinetuneRunning,requestPause,waitUntilFinetuningPauseComplete}() and to use LlamaFinetuner::ProgressCallback.
• CMakeLists.txt compiles LlamaFinetuner.cpp into both the addon and cli_tool targets.

🧪 How was it tested?

• Existing finetune integration tests in packages/llm-llamacpp/test/integration/ exercise the moved code paths (train + pause/resume + adapter save). No test signatures changed.
• C++ unit tests build with STANDALONE_TEST_BUILD; LlamaFinetuner.cpp is fully guarded by #ifndef STANDALONE_TEST_BUILD so the test build sees only the inline ctor/dtor (which is all LlamaModel.cpp references in that mode).

[gianni-cor]

Could you also update packages/llm-llamacpp/docs/finetuning.md as part of this refactor?

A few sections still describe the old ownership/API shape: LlamaModel::finetune(), LlamaModel::requestPause(), checkpoint state stored in LlamaModel, and requestPause() directly calling llama_opt_request_stop(ctx). With this PR, LlamaModel::process() delegates to finetuner_.finetune(...), pause/resume state lives on LlamaFinetuner, and requestPause() only sets pauseRequested; the optimizer stop happens later from the finetuning helper callback path.

This is docs-only, but the current text will be misleading for anyone debugging pause/resume or following the backend flow diagrams after the split.

[github-actions]

Tier-based Approval Status

**PR Tier:** TIER1

**Current Status:** ✅ APPROVED

**Requirements:**
- 1 Team Member approval ✅ (1/1)
- 1 Team Lead OR Management approval ✅ (1/1)



---
*This comment is automatically updated when reviews change.*

[gianni-cor]

/review