v1.2.5

Fix: proper async initialization with spawn multiprocessing guard

Root cause: Lazy initialization triggered inside RunPod's running event loop, causing "This event loop is already running" error.

Solution:

• handler.py: Eager initialization at module load (before runpod.serverless.start) with multiprocessing spawn guard
• engine.py: Lazy async initialization via _ensure_initialized() called on first generate() request

This matches the official RunPod worker-vllm pattern while supporting vLLM V1's spawn multiprocessing.