Fix ART runtime compatibility with vLLM 0.25

[bradhilton]

Summary

• support both the vLLM 0.23/0.24 OpenAIServing layout and the vLLM 0.25 GenerateBaseServing layout when installing ART's LoRA update coordinator
• fail closed when an unexpected nested import is missing instead of masking an incompatible runtime
• execute the CPU-safe compatibility patch in ART's release smoke check

Root cause

Caladan's DeepSeek V4 image intentionally installs art-vllm-runtime without dependencies alongside vLLM 0.25.1. vLLM 0.25 moved the shared serving constructor from vllm.entrypoints.openai.engine.serving.OpenAIServing to vllm.entrypoints.generate.base.serving.GenerateBaseServing. ART imported only the old location, so the production canary crash-looped before model startup.

Validation

• focused runtime layout/import/plugin tests: 3 passed
• related DSV4/runtime patch tests: 4 passed
• direct source checks against vLLM 0.23 and vLLM 0.25.1
• Ruff, format, ty, lock check, and pre-commit passed
• Caladan Make ./.art default root path when not in git repo #89 disposable DeepSeek vLLM 0.25.1 image build executed the focused coordinator patch successfully before GPU startup

The full runtime-isolation file has 9 passing tests and 4 unrelated host-environment failures caused by vLLM INFO output contaminating JSON and GPU-sensitive TileLang imports on CPU.