Keep failed LoRA safe merges from changing base weights

[Robertboy18]

I was looking at the safe_merge path with lora_bias=True and noticed that the base weight was assigned before the bias candidate was validated. If bias validation then raises, the weight stays changed even though the adapter was never marked as merged, so unmerge() cannot restore it.

This checks the weight and bias first and only commits them once both are valid, for linear and convolutional LoRA layers. I also added CPU regression coverage for non-finite adapter bias and biasless target layers.

Tests:

• pytest -q tests/test_custom_models.py -k "lora_safe_merge_does_not_mutate_base_layer_on_non_finite_bias or merge_with_lora_bias_when_base_layer_has_no_bias_warns_and_raises or glora_safe_merge_does_not_corrupt_base_layer_on_non_finite_adapter"
• existing healthy safe_merge cases with LoRA bias for Linear, Conv2d, and Conv3d
• Ruff format and lint checks

I also have a small TorchLean formalization of the failed-merge atomicity property and can attach it if useful :)

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BenjaminBossan]

Thanks for this fix, it looks good. Could you please merge with the latest main branch and ensure that make style passes?

A small ask, as this is something I noticed while reviewing the PR: For lora.Embedding, lora_bias is not supported, but this is checked in __init__. It would be better to check this in update_layer instead. No test is necessary for this. Thanks.

[Robertboy18]

Thanks! Rebased onto current main, moved the Embedding lora_bias validation into update_layer, and ran make style plus the focused merge tests (7 passed) :)