fix(config): surface LoRA model import failures

[morluto]

Summary

When LoRA target modules are not configured explicitly, UniRL tries to import the configured model class so it can infer the correct linear-layer scope. If that import fails, the old code logged only at DEBUG level and returned with target modules still unset. SGLang then falls back to wrapping every linear layer, which can make rollout adapter coverage differ from the training configuration without an actionable signal.

This change promotes the diagnostic to WARNING and states the exact fallback behavior. The existing fallback remains non-raising so configurations that intentionally rely on downstream discovery keep their current control flow.

Related Issue

Fixes #327.

Test Plan

• Focused import-resolution harness: missing model import emitted one warning, preserved target_modules=None, and left the configuration unchanged.
• python -m compileall -q unirl
• git diff --check abc05c1..HEAD

Compatibility / Risk

No API or configuration schema change. Import failures are now visible at WARNING level; the existing fallback behavior is unchanged.

Reviewer Notes

The important review point is the distinction between reporting the unresolved model class and changing the existing fallback contract. This PR only makes the silent failure visible.

Checklist

• Reviewed the changed code and removed unrelated artifacts.
• Updated validation coverage appropriate to the existing repository conventions.

[haonan3]

Thanks for the audit pass. I'm closing this one, because the enclosing function is not reachable — the log level is a real inconsistency, but nothing can observe it.

validate_lora_target_modules has no call sites. grep -rn over main returns only its own definition (unirl/config/validation.py:202) and the re-export in unirl/config/__init__.py:18,31. git grep at a1f85967 (initial release) through main shows it has never had a caller.

Even if it were wired, it could not reach the branch this PR edits. It reads cfg.model.use_lora (validation.py:218), and no shipped recipe defines a top-level model: key — diffusion recipes use model_config: (18 files), AR recipes have neither. The call would raise ConfigAttributeError at line 218, well before the except at 229.

And the branch that would actually fire is a different one. No class in the tree implements default_lora_target_modules (grep -rn 'def default_lora_target_modules' → nothing), so control flow would exit at validation.py:239-241 (if not callable(fn): return) — which logs nothing at all, and which this PR does not touch.

One correction for the record: the appended "SGLang will wrap every linear layer" is only true on the diffusion path (sglang/multimodal_gen/runtime/pipelines_core/lora_pipeline.py, is_target_layer returns True for every module when lora_target_modules is None). On the SRT/AR path, server_args.py asserts instead — lora_target_modules=None with no lora_paths is a hard startup failure, and "all" is an explicit opt-in sentinel. Hardcoding the diffusion consequence into a validator that is generic over cfg.model would be misleading if it is ever wired for AR LoRA.

The genuinely useful finding here is the one underneath: the whole cross-component half of unirl/config/validation.py is dead code — validate_lora_target_modules, validate_weight_sync_contract, validate_offload_contract, validate_keep_local_contract, and validate_multi_track_mini_batch_geometry all have zero callers, and they read a config schema (cfg.model / cfg.run / cfg.training / cfg.placement) that no recipe uses. That is worth an issue: either wire them up against the real schema, or delete them. I'd welcome that one.

General note for the next batch: please confirm the trigger condition is reachable — name the config or the call chain that gets there — before filing. Four of the six PRs in this group turn out to change code that nothing can execute, and that check would have caught them upfront.