fix: raise default VLLM_STARTUP_TIMEOUT to 1800s and expose it in the hub env schema

[velaraptor-runpod]

What

• Raises the default startup health-check deadline in src/main.py from 1200s to 1800s (VLLM_STARTUP_TIMEOUT override unchanged).
• Adds VLLM_STARTUP_TIMEOUT to the .runpod/hub.json env schema (advanced, default 1800) so hub/console deploys surface it; today the knob exists in code but is invisible to users.
• Keeps docs/configuration.md in sync.

Why

On 2026-10-06 a 4×H200 worker serving DeepSeek-V4.1-Flash (475 GB, fp8_ds_mla) had its weight load stretched to ~13 min by same-host contention from overspawned sibling workers. The 1200s watchdog fired and SIGTERM'd the vLLM process 13 seconds before it printed "Application startup complete", forcing a full container restart and another multi-minute engine bring-up. For 400 GB+ models, 1200s leaves no headroom for variance in page-cache warmth, host contention, or disk pressure — and killing an actively-loading backend wastes the entire load it just paid for.

1800s covers the observed worst case (789s weight load + graph capture + warmup) with margin, while still bounding genuinely stuck starts.

Not in this PR

Follow-up worth a separate issue: make the watchdog progress-aware (don't SIGTERM a backend still actively loading weights) instead of purely wall-clock.

Testing

pytest tests — 142 passed. hub.json parses and matches the sibling entry shape.

[promptless]

Promptless documentation updates

• Document vLLM worker startup error handling in Serverless troubleshooting adds a startup-timeout troubleshooting section and a VLLM_STARTUP_TIMEOUT environment variable entry covering the new 1800-second default.