[LoRA] apply .alpha in lora_A/lora_B Qwen-Image LoRAs

[dkackman]

What does this PR do?

Fixes #14938

When a Qwen-Image LoRA's keys are already named lora_A/lora_B, the converter threw away the per-module .alpha. LoRAs trained with alpha ≠ rank therefore loaded at the wrong strength. For example, e-n-v-y/Qwen-Image-2.1-Fix-v2.0 loads at about a third of its intended strength. ai-toolkit and ComfyUI LoRAs commonly use this layout.

This PR folds the alpha into the weights, the same way the converter's lora_down/lora_up path and the Z-Image converter already do.

Behaviour changes:

• Any Qwen-Image LoRA (20B and 2.1) saved as lora_A/lora_B with alpha ≠ rank now loads at alpha / rank, not 1.0. Users who compensated with lora_scale will see different results.
• A lora_A without a matching lora_B (or the reverse) now raises an error instead of being passed through, as in the lora_down/lora_up path.

LoRAs saved with lora_down/lora_up keys are unaffected, because alpha was already applied there. That includes the lightx2v/Qwen-Image-Lightning LoRAs used in the docs.

Related: #14932. 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. Left for review:

• An alpha whose name doesn't match <module>.alpha is still dropped without a warning, as before. Removing that cleanup would make it raise instead. I kept the existing behaviour, but I'm happy to change it.
• The test checks the converted state dict rather than running a pipeline with the LoRA loaded. I can add a full pipeline test if you'd like one.

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.