Add CI: check PR-changed server.yml against vllm-project/recipes

[wjhrdy]

SUMMARY:
Adds this repo's first GitHub Actions workflow (.github/workflows/recipes-check.yml + .github/scripts/check_recipes.py). On every PR touching a server.yml, it diffs only the changed model(s) against upstream vLLM community serving guidance (vllm-project/recipes, via the hosted recipes.vllm.ai API) and posts findings as a job summary + sticky PR comment, linking each matched model to its recipe page as evidence. A high-confidence correctness conflict (reasoning-parser/tool-call-parser/tokenizer-mode/config-format/load-format) fails the check and blocks merge (--fail-on correctness); everything else (missing/extra, performance notes, fuzzy matches) is advisory-only and never fails the build.

This follows a manual, repo-wide review done this session that found a real bug (wrong reasoning-parser on Qwen/Qwen3.6-35B-A3B, fixed in #106/#104) but also produced two false alarms once checked against actual vLLM/harness behavior. The check is deliberately tuned to avoid reproducing that noise on every PR:

• tool-call-parser: a hardcoded wrong value is the same class of bug as a wrong reasoning-parser (both mis-select an output-parsing implementation), so an explicit conflict renders top-tier and blocks merge, same as reasoning-parser/tokenizer-mode/config-format/load-format. "Missing"/"extra" is still never flagged for it — nm-cicd's OCP harness independently injects it at deploy time, and this repo can't see that harness to know if it applies.
• enable-auto-tool-choice (a boolean toggle, not a parser selection): same missing/extra suppression, but conflicts stay advisory-only, non-blocking.
• kv-cache-dtype: always a performance note, never correctness — vLLM's own docs frame the default as the higher-fidelity choice for standard attention backends.
• Fuzzy/ambiguous recipe matches are shown separately and never drive the main findings or the block-merge gate.
• "Expected divergence" flags (max-model-len, tensor-parallel-size, chat-template, trust-remote-code, ...) are filtered out entirely.
• Network failures and "no upstream recipe for this model" are treated as normal, non-error outcomes, and never fail the check.

TEST PLAN:

• Local dry runs against 6 scenarios: real bug present (flags reasoning-parser diff prominently), bug fixed (no top finding), common/-only change (graceful skip message), unrelated file change (graceful no-op), unmatched model (graceful "no recipe found"), vendored argv_to_config unit-sanity check against upstream's documented example — all pass.
• This PR doesn't itself touch a server.yml, so the pull_request path filter doesn't fire automatically here. Confirmed end-to-end on a real pull_request event (not just workflow_dispatch) via throwaway PR [DEMO, do not merge] Evidence: tool-call-parser top-tier + recipe links #109: deliberately reintroduced reasoning-parser: deepseek_r1 + tool-call-parser: hermes on Qwen/Qwen3.6-35B-A3B, confirmed both rendered top-tier with a working recipe-page link in the posted PR comment (evidence).
• Confirmed --fail-on correctness actually blocks merge: reintroducing the reasoning-parser bug on [DEMO, do not merge] Evidence: tool-call-parser top-tier + recipe links #109 made the check-recipes status fail (run); reverting to the correct value made it pass (run). Note: this only actually blocks a merge button if check-recipes is added as a required status check under branch protection — that's a separate, repo-wide setting not touched by this PR.
• [DEMO, do not merge] Evidence: tool-call-parser top-tier + recipe links #109 stays open only as a running evidence log (its base predates the real fix, so it must never merge).