feat(server): add ft info and a pre-load memory preflight

[KarrAcaRn]

I had an issue with a 21GB model not loading into a 24GB card.
It is possible to load this model but only with the right settings.
And i dont like that you only realise this after 10 minutes of loading and not at the begining.

It also makes it possible to have a better understanding of a model.

What

ft info <model> [ft serve flags] forecasts what ft serve would put on the GPU, and whether it fits, without reading a single weight. ft serve runs the same forecast between building the model and loading its weights, and refuses a configuration that cannot fit before spending minutes on the load.

Today a configuration that does not fit fails only after all weights are loaded, with an assert deep in KV sizing, and there is no way to see the trade-off between context length, concurrent requests and the MoE expert cache without trial and error.

How

• The forecast builds the model on the meta device, exactly as Engine.__init__ does, so the resident weights are the tensors the loader would materialize.
• Every pool is sized by the engine's own code, not a copy of it: _startup_kv_budget, the pool family's kv_cost / plan_num_pages, state_pool_bytes, and plan_moe_cache_auto. Two small refactors make these reusable: plan_num_pages is split out of solve_num_pages, and the moe-cache-auto plan is shared.
• Only what the engine does not price up front is a heuristic (load overhead, prefill activations, CUDA graphs). The verdict never refuses on a heuristic alone, only when the engine's own solve would fail.
• Free memory is read before the arch probe creates this process's CUDA context, so the context is not counted twice.
• When the verdict is not "fits", ft info prints tips: each flag change is re-evaluated through the same forecast (--memory-ratio, --max-prefill-length, --kv-reserve-tokens, --moe-strategy, --cache-type, ...), plus a suggested combination.
• ft serve preflight:
  • "fits" -> one info line.
  • "tight" -> a warning with the forecast and the tips.
  • "does not fit" -> refuses with the reason and a suggested fix. --skip-preflight loads anyway.
• ft info --json gives the same report for tools. --gpu-memory-gib / --gpu-free-gib forecast for another GPU. Documented in docs/cli.md.

Tested

RTX 4090 24 GB (sm_89), driver 595.91.07, CUDA 13.1, 8-core CPU, 30 GB RAM, branch on main d3512b4.
Forecast vs. the engine's own log on a real start:

Checkpoint	Command	Forecast	Actual
RadixArk/Qwen3.8-27B-NVFP4	ft info/serve <model> --text-model-only --max-running-requests 1 --memory-ratio 0.95	12931 KV tokens, 0.87 GiB free after init	12688 KV tokens, 0.86 GiB free
RedHatAI/Qwen3.6-35B-A3B-NVFP4	same flags	9755 expert slots, 8276 KV tokens	9859 expert slots, 8236 KV tokens

• ft serve RadixArk/Qwen3.8-27B-NVFP4 --text-model-only --memory-ratio 0.5 is refused after ~15 s with "no room for the KV cache" and a suggested fix, before any weight is loaded.
• pytest tests (-m "not slow"): new tests in tests/engine/test_forecast.py, tests/server/test_info.py and tests/kvcache/test_pool_sizing_surface.py pass. The 5 failures (test_fp8_pertensor_linear x2, qwen4_exp/test_qsa_backend chunked prefill x3) fail identically on main.

Follow-ups

The forecast prices exactly what main does today.
Once these open PRs are merged, small follow-up PRs extend it to match:

• fix(engine): charge the attention workspace in moe-cache-auto sizing #562 (attention workspace charged in moe-cache-auto sizing): pass the workspace through the shared plan_moe_cache_auto. Until then it is priced only as memory outside the budget.
• feat(engine): --vram-reserve-mb keeps VRAM free at the largest prefill #574 (--vram-reserve-mb): price the reserve and the expert-cache shrink it triggers.
• feat(kvcache): store the KV cache as fp8 e4m3 codes (--kv-cache-dtype… #354 and feat(kvcache): add nvfp4 kv quantization #408 (--kv-cache-dtype fp8 / nvfp4): add KV-dtype tips showing the extra context each dtype buys.

[KarrAcaRn]

I'm think this PR would have given a better error message in the case of #561