fix(LOAD-CONFIG-SURFACE): a list-valued num_experts_per_tok makes the whole hf_config parse throw

Row: LOAD-CONFIG-SURFACE

Found by wave PORTQ-2 re-deriving PORT-NOW entry 74 of 5559679229..e126687a9a
(#2646). Upstream:
e76b71f659 vllm#51179. Previously read by #2524's sample
(.agents/sync/2026-09-01-cdefd9d.md §13 item 5, "One line, latent");
re-verified at e24ec8bfd, and the failure mode is sharper than that note
records.

Not a wrong number — a hard refusal

src/vllm/transformers_utils/hf_config.cpp:458 reads

    cfg.num_experts_per_tok = GetInt(text, "num_experts_per_tok", 0);

and GetInt (:22-26) is it->get<int64_t>() with no array branch. On a
list-valued key nlohmann throws json::type_error, which the enclosing catch at
:593-595 converts into
std::runtime_error("hf_config: bad field type in " + path + ...).

So the checkpoint upstream's PR unblocks does not load here at all. Upstream's
post-fix behaviour is max(list, default=0).

A second, adjacent absence — stated so it is not mistaken for this one

Upstream reads the key through getattr_iter over
["num_experts_per_tok", "moe_topk", "moe_top_k"]. moe_topk and moe_top_k
have zero hits in src/ and include/, so those two aliases are unread here
regardless of list-ness. That is a separate gap this entry surfaces and does not
own.

Size

A list-tolerant read for this key — take the max of a JSON array, keep the scalar
path byte-identical — plus a fixture case. Roughly 10-14 lines over
src/vllm/transformers_utils/hf_config.cpp and tests/vllm/test_hf_config.cpp,
which this row's matrix entry already names as its local anchors.

Nothing was executed for this finding: no build, no test, no GPU.

Start with src/vllm/transformers_utils/hf_config.cpp around GetInt and the num_experts_per_tok read, then inspect tests/vllm/test_hf_config.cpp. Add the named fixture case and run the focused configuration tests. Done means scalar handling remains unchanged and a list-valued key loads using its maximum instead of throwing a bad-field-type error.