[vLLM][XPU] 修复 torch.compile 跟踪时 LoRA 算子被裁剪的问题

[sicnuyudidi]

概述

修复 vLLM 在 torch.compile compilation tracing 阶段，XPU Punica 的
no-adapter fast path 错误地从 compiled graph 中 prune LoRA operations 的问题。

Fixes #634.

根因

PunicaWrapperXPU.no_lora 是 mutable host-side Python state。常规 profiling
batch 没有 active adapter，因此 compilation tracing 时 self.no_lora=True。
现有的 Python early return 会在 tracing 阶段被固化到 compiled graph 中，导致
LoRA operations 被直接 prune。之后即使 adapter 请求的 request-time mapping
正确，compiled graph 也不会再执行 LoRA delta，最终表现为请求成功但 LoRA
effect 被静默忽略。

改动

• 新增 _should_skip_lora()：在 eager execution path 下保留 no-adapter fast
  path，但在 compilation tracing 阶段禁止使用该 shortcut。
• 在五个 dense XPU Punica LoRA entry points 中统一使用该 helper。
• 增加 XPU regression test，覆盖 eager 和 compiling states。

实现说明

torch.compiler.is_compiling() 是“当前 Python frame 正在被 TorchDynamo
捕获”的上下文谓词，不是服务是否启用 torch.compile 的全局开关。helper
采用显式 compile-first 分支：

def _should_skip_lora(self) -> bool:
    if torch.compiler.is_compiling():
        return False
    return self.no_lora

这样 tracing 期间不会读取 mutable self.no_lora，LoRA operators 必须保留在
compiled graph 中；非 tracing 的 eager path 仍可根据当前 batch 的
self.no_lora 使用 fast path。

验证

• 已确认 original compiled execution path 会丢失 LoRA effect。
• 已确认使用 --enforce-eager 后 LoRA effect 恢复。
• 已确认在 compile warmup 期间保留 LoRA operations 后，LoRA effect 恢复。
• 已确认关闭 debug overrides 后，本 PR 的 compile-aware guard 仍能恢复 LoRA
  effect。
• 已确认应用本修复后，base-model behavior 不受影响。
• 已使用标准 git apply 将更新后的 llm-scaler patch 成功应用到干净的上游
  vLLM v0.21.0 源码。
• 已对修改后的文件执行 Python 语法检查和 git diff --check，均通过。
• 已覆盖 compiling × no_lora 四态真值表，并验证 tracing 分支不会读取 mutable host state。

已在 Intel XPU 环境完成 end-to-end validation。