fix: 兼容 vLLM 0.23 的权重加载与 spark25 工具解析

[MittaPei]

Which issue(s) this PR fixes:

Fixes #8

Description:

Issue #8 的首个异常来自 API 版本差异：vLLM 0.23 的 WeightsMapper 不接受 orig_to_new_stacked。但只移除这个参数并不足以修复原始启动命令：

1. Spark checkpoint 分开保存 gate_proj / up_proj，旧版 vLLM 仍需将它们分别装入 packed gate_up_proj 的 shard 0/1；
2. 原始命令启用了 --tool-call-parser spark25，而 vLLM 0.23 的 vllm.tool_parsers.utils 还没有插件当前导入的 find_tool_name。

本 PR 做了以下局部修改：

• 按 API 能力而不是版本字符串选择权重加载路径；
• 在旧版路径中保留 gate/up 分片映射、已融合 q_k_v_proj 的直接加载、PP missing 参数处理和 tied lm_head 跳过；
• 在较新 API 上继续使用原生 AutoWeightsLoader + WeightsMapper；
• 对缺少 find_tool_name 的 vLLM 提供最小兼容 helper，并兼容两类工具对象形态；
• 增加 packed-weight 回归测试、固定 vLLM 0.23.0 的 CI job，并更新 README 与 CHANGELOG。

验证结果：

验证	固定环境	结果
pytest tests/ -q	vllm/vllm-openai:v0.23.0	3 passed
较新 API 回归	vLLM 81efe788… 源码快照	3 passed
额外固定兼容检查	vLLM 0.23.0	7/7 checks passed
Ruff + wheel/sdist 构建	Python 3.12	PASS
真实冷启动	官方 vLLM 0.23.0 镜像 + 官方 Spark-X2.5-4B revision	5/5 权重分片加载，服务健康
普通对话	thinking=false、temperature=0、固定 seed	返回 合肥
原生工具调用	tool_choice=auto + spark25	get_weather({"city":"合肥"})

真实运行固定了模型 revision 1e4c2477f330d1f11304d0dc092a9dbf4075f470 和 vLLM 镜像 digest sha256:6d8429e38e3747723ca07ee1b17972e09bb9c51c4032b266f24fb1cc3b22ed8f。为控制共享 GPU 资源，max_model_len 设为 131072。

补充复现材料与完整原始记录：MittaPei/spark-x2-5-vllm-review-case

Checklist:

• Code follows the project's style guidelines (ruff check .)
• Tests pass locally (pytest tests/ -q)
• Relevant documentation is updated (README.md, docstrings)
• Vendored files under src/vllm_spark2_5_plugin/ are noted if changed

Special notes for reviewers:

本 PR 修改了 vendored 文件 spark2_5.py 和 spark2_5_tool_parser.py；来源仍为 README 记录的 vLLM commit 81efe7883f30582696b69f9b9ea93c4819a8c608，原有 SPDX 标识保持不变，仅在其上叠加局部兼容层。两处文件依赖 vLLM 内部 API，因此使用能力检测同时覆盖 vLLM 0.23 和插件记录的较新 API 快照。

尚未验证量化 checkpoint、多机、Pipeline Parallel 实机运行或 vLLM 0.28；最终冷启动也没有复刻 Issue 报告者的加速器插件环境。

AI 辅助说明：我使用 Spark-X2.5-4B 对冻结候选提交做受控代码审查，并使用通用编码助手辅助实现、测试和文档整理；我逐项复核补丁与验证结果后提交，并对本次贡献负责。正确性以本 PR 的确定性测试和真实运行结果为准。