[LoRA] split fused img_mlp.gate_up LoRAs for Qwen-Image-2.1

[dkackman]

What does this PR do?

Fixes #14937

ComfyUI and ai-toolkit LoRAs for Qwen-Image-2.1 target the fused SwiGLU img_mlp.gate_up layer. diffusers keeps that layer as two separate layers, img_mlp.gate_layer and img_mlp.proj, so the converter passed the gate_up keys through, PEFT dropped them as unexpected keys, and the LoRA loaded without its MLP update and without any error.

This PR splits those LoRAs into the two layers when they're loaded, gate rows first, in the same order convert_qwen_image21_transformer_checkpoint_to_diffusers uses for full checkpoints. lora_A is shared and lora_B is split by rows, so the split is lossless. Nothing changes for the original Qwen-Image, which has no gate_up layer.

Checked against real files: converting ML-Intern-lab's fused doodle-in LoRA gives exactly the pre-split file they publish. The Outpaint-v2, grainscape and AnyAngle LoRAs map fully onto the 2.1 model's layers, with no keys dropped.

Related: #14933. That PR fixes .alpha being dropped from lora_A/lora_B checkpoints, which is a separate bug. Both PRs edit _convert_non_diffusers_qwen_lora_to_diffusers, so whichever merges second needs a small rebase.

Self-review notes

I ran the self-review skill. It found no blocking issues. I removed the dead code it flagged (an unreachable else and a redundant early return). Left for review:

• _split_qwen_image21_fused_gate_up_lora has a single caller. I kept it separate so the 2.1-specific logic and its docstring stay out of the shared Qwen converter, but I'm happy to inline it.
• On this branch, .alpha in lora_A/lora_B checkpoints is still dropped. That's deliberate: [LoRA] apply .alpha in lora_A/lora_B Qwen-Image LoRAs #14933 handles it.

Before submitting

• Did you use an AI agent (Claude Code, Codex, Cursor, etc.) to help with this PR? If so:
  • Did you read the Coding with AI agents guide?
  • Did you run the self-review skill on the diff?
  • Did you share the final self-review notes in the PR description or a comment?
• Did you read the contributor guideline?
• Did you read our philosophy doc? (important for complex PRs)
• Was this discussed/approved via a GitHub issue or the forum? Please add a link to it if that's the case.
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests?
• Are you the author (or part of the team) of the model/pipeline (only applicable for model/pipeline related PRs)?

Who can review?

@sayakpaul

🤖 Generated with Claude Code

[github-actions]

Hi @dkackman, thanks for the PR! It does not appear to link an issue it fixes. If this PR addresses an existing issue, please add a closing keyword (e.g. Fixes #1234) to the PR description so the issue is linked. See the contribution guide for more details. If this PR intentionally does not fix a tracked issue, a maintainer can add the no-issue-needed label to silence this reminder.

Please note that PRs without a linked issue are likely to be automatically closed 10 days after this notice.

Once the PR links an issue (or gets the no-issue-needed label), you can ignore this message — it stays here as a comment, but it no longer applies.