Revert deepseek_weight_loader.py changes from #25141

[nanjiangwill]

Summary

• The deepseek_weight_loader.py changes in support kimi 2.5/6 lora (logprob diff exist) #25141 (persistent `cached_a_proj` + unconditional `.detach().clone()`) were a workaround for `q_a_proj` and `kv_a_proj_with_mqa` landing in different chunks during chunked weight updates. The fusion to `fused_qkv_a_proj_with_mqa` only fires when both halves are visible in the same `load_weights` call, so without persistence, a split chunk produced partially-fused weights.
• The proper fix is on the sender side: pair the two halves before chunking so they always arrive in the same `load_weights` call. Done in radixark/miles#1361, mirroring the approach slime adopted in THUDM/slime#1753.
• With sender-side pairing in place, `cached_a_proj` only needs to live for one `load_weights` call, matching the original upstream behavior. This PR reverts the loader back to that form.

Why revert on `sglang-miles` and not main

• support kimi 2.5/6 lora (logprob diff exist) #25141 was merged onto `sglang-miles`, not main. This is the smallest possible un-doing — keeps the K2.5 LoRA work (mem_pool / triton kernels / load-from-tensors RPC) and only removes the deepseek-loader workaround that's no longer needed.
• The remaining files from support kimi 2.5/6 lora (logprob diff exist) #25141 will be carved into focused PRs against main separately.

Test plan

• Sender-side pairing (Pair q_a_proj / kv_a_proj_with_mqa in the bridge weight iterator radixark/miles#1361) must land before this PR is exercised end-to-end.
• Run K2.5 LoRA on `sglang-miles` + the miles pairing fix and confirm `train/train_rollout_logprob_abs_diff` stays bounded (~0.03) across steps.
• Existing non-MLA / non-chunked-update behavior is unchanged because the diff exactly restores the pre-support kimi 2.5/6 lora (logprob diff exist) #25141 state of this file.

---

CI States

Latest PR Test (Base): ❌ Run #28424125993
Latest PR Test (Extra): ❌ Run #28424125889

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!