feat(LoRA): allow LoRA layer patcher to continue past unknown layers

[keturn]

Summary

Chroma users will want to apply FLUX LoRA to Chroma models, despite the differences.

This PR changes the default behavior of LayerPatcher to continue operating (with a warning) after attempting to patch a missing layer.

In the case of Chroma, we have a good idea of which layers those will be, so we also provide a way to disable the warning for the expected layers.

Related Issues / Discussions

• Chroma discord thread
• overall Chroma issue: [enhancement]: support lodestones/Chroma #7986

QA Instructions

No code in core uses this yet, though do test that existing LoRA still work.

With this PR, the Chroma node should be able to run with FLUX LoRA.

Merge Plan

N/A

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[keturn]

Potential alternative: The Chroma node could attempt to trim those layers out of the LoRA before it's passed to the LayerPatcher, maybe?

[hipsterusername]

Would it make sense to just more intentionally try to integrate Chroma support? I'm not tracking that model, but we are supportive of it if you think worthwhile

[keturn]

I think the Chroma model is going to have a big role in the Flux-derived-local-models space, so full Chroma support would be great. But I expect the outlook on this particular PR is much the same either way—I'm not sure that we'd do this "load a partially-compatible LoRA" problem any differently if it were in core.

[psychedelicious]

I agree that this more tolerant handling is how it should work anyways.