Add LiteRT-LM LoRA adapter support

[leehack]

Summary

The new LiteRT-LM backend currently rejects LoRA use:

• ModelParams.loras is rejected during .litertlm model load.
• setLora(...), removeLora(...), and clearLoras() report UnsupportedError for LiteRT-LM contexts.

This is intentionally out of scope for PR #167, but we should track it as follow-up work instead of leaving it as a permanent limitation.

Current evidence

The pinned litert-lm-native@v0.12.0 C ABI exposes engine/conversation/tokenizer/constrained-decoding helpers, but no stable exported litert_lm_*lora* function for Dart FFI to bind. The macOS artifact does contain internal C++ symbols such as SessionConfig::SetScopedLoraFile(...), so upstream/native support may exist below the C wrapper layer.

We should not bind Dart directly to mangled C++ symbols. This needs a stable native C ABI first.

Proposed work

1. Investigate upstream LiteRT-LM LoRA semantics: load-time only vs session-scoped vs dynamic adapter switching.
2. Add stable C wrapper functions in litert-lm-native if upstream exposes a usable API.
3. Publish updated runtime artifacts for supported platforms.
4. Add Dart FFI bindings in llamadart.
5. Map the API to existing high-level LoRA operations where possible:
   • ModelParams.loras
   • setLora(...)
   • removeLora(...)
   • clearLoras()
6. Add native smoke tests with a real .litertlm model and adapter when a test artifact is available.
7. Update capability docs and backend-selection guidance.

Acceptance criteria

• LiteRT-LM either supports the existing LoRA API with documented behavior, or docs explain the exact unsupported operations and native/runtime reason.
• Unsupported combinations fail early with actionable errors.
• Runtime artifact version and platform support are documented.

[leehack]

Update: the narrow upstream LiteRT-LM PR is now open and ready for review:

google-ai-edge/LiteRT-LM#2508

Current upstream scope:

• LiteRT-LM session config stores text/audio LoRA paths alongside scoped LoRA file handles.
• C API LoRA path setters populate those paths for downstream FFI users.
• ResourceManager assigns, loads, and reuses text LoRA IDs by adapter path.
• LlmLiteRtCompiledModelExecutorBase supports LoadLoRA / UseLoRA, injects active LoRA buffers during decode, and preserves the LoRA ID across context clone/restore.

Validation on macOS arm64 now includes:

/tmp/bazel-7.6.1-darwin-arm64 test //runtime/framework/resource_management:resource_manager_test --test_output=errors --cache_test_results=no
/tmp/bazel-7.6.1-darwin-arm64 test //runtime/engine:engine_settings_test //runtime/framework/resource_management:resource_manager_test //runtime/components:lora_manager_test //runtime/components:lora_test --test_output=errors
/tmp/bazel-7.6.1-darwin-arm64 build //runtime/executor:llm_litert_compiled_model_executor //runtime/framework/resource_management:resource_manager //c:engine_cpu
/tmp/bazel-7.6.1-darwin-arm64 test //c:engine_test --test_output=errors

The resource-manager test uses the real upstream fixtures test_lm_lora.litertlm and test_lora_rank32_f16_all_ones.tflite, then runs Prefill + Decode through SessionConfig -> ResourceManager -> compiled text executor -> LoraManager.

Downstream llamadart work should wait for upstream maintainer direction on PR #2508, unless we choose to ship a vendored LiteRT-LM runtime override first.