feat(model-manager): support LyCORIS LoKr LoRAs for Krea-2

[Balrog994]

Summary

Krea-2 LoRAs in LyCORIS LoKr format can't be installed at all at the moment. The probe turns them away with:

model does not match Krea-2 LoRA heuristics (no complete lora_A/B or lora_down/up pair)

I hit this with an adapter trained in ai-toolkit, which emits LoKr by default, so I'd guess a fair few of the Krea-2 LoRAs going around are in the same boat.

The Krea-2 probe only knows about lora_A/lora_B and lora_down/lora_up. LoKr carries Kronecker factors instead (lokr_w1/lokr_w2, or the factored _a/_b pairs plus an optional lokr_t2), so _has_complete_lora_pair() says no and the adapter is never identified. Setting the base by hand doesn't get you anywhere either, that path goes through the same helper.

There's a second one further down: _SUFFIX_TO_VALUE_KEY doesn't list the lokr_* suffixes, so even past the probe _group_by_layer() would drop the weights and leave every layer holding nothing but its alpha.

The rest was already there. LoKRLayer exists, any_lora_layer_from_state_dict() reaches for it the moment it sees lokr_w1, and the Qwen-Image converter handles LoKr fine. Only the Krea-2 side was never wired up, which fits it being marked WIP in #9304.

So this adds the two missing pieces: a _has_lokr_layer() helper that both config gates consult, and the lokr_* suffixes in the converter's suffix map. I left the signature-module check alone, so a LoKr that only touches generic transformer blocks still won't be claimed as Krea-2.

Related Issues / Discussions

Follows on from #9304.

QA Instructions

Take any ai-toolkit LoKr for Krea-2 (keys look like diffusion_model.txtfusion.<block>.attn.wq.lokr_w1) and install it through the Model Manager. Before, it's rejected with the error above. After, it installs as base=krea-2, format=lycoris and turns up in the LoRA picker.

I tested with a 32-module adapter on the text-fusion stage against a GGUF-quantised Krea-2 Turbo. It converts to 32 LoKRLayers, every target key resolves to a real nn.Linear in Krea2Transformer2DModel, the reconstructed weight (4×4 ⊗ 640×640 = 2560×2560) matches the layer it patches, and generation comes out visibly different with the LoRA switched on.

8 new tests, covering full and factored LoKr, the native→diffusers key renaming, and that a LoKr without the Krea-2 signature modules still gets turned away. tests/backend/patches/ and tests/backend/model_manager/ pass (1030 passed, 133 skipped, 1 xfailed), as do ruff check and format. I only ran them on 3.12/Windows locally, so the rest of the matrix is on CI.

Merge Plan

Nothing special, backend only.

Checklist

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

[Balrog994]

Merged main in — thanks @Pfannkuchensack for keeping the branch current while this sat.

#9449 landed just after your last merge and touched the same four files, which is where the
conflict came from. The textual part was trivial (we both added imports). The part worth flagging is
that the two changes overlap behaviourally, and I've changed one of your test expectations because
of it.

Your per-module gate converts a flattened module only when every suffix on it is one
_group_by_layer knows, and LyCORIS algorithms stayed verbatim because lokr_* wasn't such a
suffix. This PR makes it one. So a kohya-flattened LoKr module now un-flattens and lands on its real
Linear instead of degrading to the per-layer "Failed to find module" warning:

lora_unet_txtfusion_layerwise_blocks_0_attn_wq.lokr_w1
  before: lora_transformer-lora_unet_txtfusion_layerwise_blocks_0_attn_wq   (no-op)
  after:  lora_transformer-text_fusion.layerwise_blocks.0.attn.to_q          (LoKRLayer)

The hazard your comment guards against — the grouper's blind rsplit(".", 2) cutting inside a
dotted module path — doesn't apply to a suffix the grouper recognises, so I don't think anything is
lost here.

Concretely: two of the five parametrizations of
test_kohya_lycoris_algorithm_keys_do_not_abort_the_load were failing, both the LoKr ones. Rather
than special-case them out I moved the expected layer into the parametrization — the LoKr cases
expect the converted module, hada_* and diff still expect the verbatim key. The invariant the
test is actually about, that a mixed-algorithm file never takes the whole adapter down, holds either
way. Also added a test for the kohya + LoKr path end to end.

If you'd rather this PR left the kohya path completely alone, the alternative is to give that gate
its own suffix set instead of reusing _SUFFIX_TO_VALUE_KEY, so LoKr stays unsupported there and
your test is untouched. It's a smaller blast radius but it means a kohya-flattened LoKr keeps
silently doing nothing, which seemed like the worse outcome. Happy to switch if you disagree.

tests/backend/patches/ and tests/backend/model_manager/ are green locally (1415 passed) and ruff
is clean.