Reported by @armanbot-jpg with a root cause and, more usefully, a control:
hand-editing `keys` in the saved adapter_config.json makes the very same
adapters.safetensors produce the tuned behaviour. That is what proves the
weights were fine and the config was not.

_apply_lora resolved `target_modules: auto` into a LOCAL variable and trained
Q/V; the writer serialised lora_cfg.target_modules, i.e. the raw "auto". On
load, linear_to_lora_layers(..., {"keys": ["auto"]}) matches no module and
load_weights(strict=False) drops all 96 LoRA tensors silently, so generation
with the adapter is bit-identical to the base model.

"auto" is the schema DEFAULT, so this was every MLX run that did not name its
modules by hand -- and the adapter_config.json exists specifically to promise
the output dir loads with mlx_lm.load(..., adapter_path=...).

Third time in this project a healthy loss curve has shipped a dead artifact
(v0.72.0's .inner. keys, #362's full-fine-tune adapter, this). The loss curve
structurally cannot see it; only the artifact can. So the repair is one shared
resolve_mlx_target_keys() rather than teaching the writer to resolve too --
two copies of "which modules did we train?" is how they drifted.

Tests first: 10 red before, 10 green after. Two are controls -- the resolved
value must never contain "auto" whatever the input, and rank/scale/dropout must
still come from the config, so a repair that hardcoded the whole block would
fail rather than pass.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>