[Bugfix] Fuse Qwen3.5 in_qkvz_proj forwarding with LoRA enabled

[Isotr0py]

Purpose

• There're 2 forwarding code path for Qwen3.5 after [Bugfix][LoRA] Fix Qwen35 LoRA #36976.
• This PR unifies them by adapting the LoRA layer implementation.

Test Plan

pytest -s -v tests/lora/test_qwen35_densemodel_lora.py

Test Result

Tests pass at both TP=2 and TP=4

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request refactors LoRA handling for Qwen3.5 and Qwen3-Next models. Key changes include introducing an expand_packed_lora method to flexibly handle LoRA adapter groups that don't match the number of slices, and unifying the input projection logic in Qwen3.5 attention by removing LoRA-specific conditional paths. The create_dummy_lora function in model_manager.py contains a 'HACK' comment, which should either be replaced with a detailed explanation of the necessary logic or improved with a more robust solution.

[gemini-code-assist]

The use of a 'HACK' comment here is concerning as it suggests the solution is not robust and could lead to future maintenance issues. Code with 'HACK' comments is often difficult to understand and easy to break.

If this logic is indeed the correct and necessary approach for handling dummy LoRA creation for packed modules like in_proj_qkvz, please replace the 'HACK' comment with a more detailed explanation. The explanation should clarify:

1. Why there's a mismatch between n_slices and len(replacements).
2. Why generating generic slice_i names is the appropriate solution for creating dummy LoRAs in this scenario.
3. How this interacts with the loading of real LoRA weights.

A clear explanation will improve code maintainability and prevent future confusion.

Alternatively, if a more robust, less 'hacky' solution is possible (perhaps by making the relationship between packed modules and slices more explicit in the model configuration), that would be preferable.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @Isotr0py.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork