[Frontend] Support min_p in the Responses API

[sungbin1015]

Purpose

The Responses API (/v1/responses) already exposes top_k as a request field
and forwards it to SamplingParams, but its natural companion min_p is
missing — even though SamplingParams (and SamplingParams.from_optional)
fully support it, and the Completions/Chat endpoints both expose it.

This adds the min_p field to ResponsesRequest, resolves its default
alongside top_k in to_sampling_params, and plumbs it through to
SamplingParams.from_optional, mirroring the existing top_k handling exactly.
Users of /v1/responses can now use min-p sampling like every other generation
endpoint.

Not a duplicate: searched open PRs/issues from several angles
(responses min_p, ResponsesRequest min_p in:body,
responses/protocol.py min_p in:body, min_p in:title, responses API sampling parameters). min_p is entirely absent from
responses/protocol.py (no matches in the file), and no open PR adds sampling
parameters to the Responses API. PR #45839 adds sampling params to the separate
Translation API only; this change is orthogonal.

Test Plan

.venv/bin/python -m pytest \
  tests/entrypoints/openai/responses/test_sampling_params.py -v
pre-commit run --files \
  vllm/entrypoints/openai/responses/protocol.py \
  tests/entrypoints/openai/responses/test_sampling_params.py \
  docs/serving/online_serving/openai_compatible_server.md

Added a min_p assertion to test_basic_sampling_params and a new
test_min_p_default verifying the neutral default (0.0).

Test Result

8 passed in 1.07s

ruff check, ruff format, and mypy all pass via pre-commit.

Related work

• [Frontend] Add sampling parameters to Responses API #32609 (merged) added the first batch of sampling parameters to the Responses API. Its description lists min_p struck through, so it was dropped before merge; I did not find the reason recorded in that thread. If leaving min_p out was a deliberate decision rather than scope trimming, please say so and I will close this.
• [Bugfix][Frontend] Honor stop_token_ids on the Responses API #56592 (open) adds stop_token_ids to the same ResponsesRequest / to_sampling_params. It is a different field, but it edits neighbouring lines in responses/protocol.py and test_sampling_params.py, so whichever lands second will need a small rebase. I will rebase this one if [Bugfix][Frontend] Honor stop_token_ids on the Responses API #56592 goes first.
• [Frontend] Support additional sampling parameters for translation API #45839 (merged) is the Translation API only, as noted above.

---

AI assistance disclosure: this PR was prepared with AI (Claude) assistance. I
have reviewed every changed line and ran the tests above myself.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[mergify]

Documentation preview: https://vllm--48084.org.readthedocs.build/en/48084/

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @sungbin1015.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[sungbin1015]

Rebased onto the latest main and resolved the docs conflict with #55912 (kept the /v1/responses/render paragraph and moved the "Sampling parameters" section below it). No code changes since the original commit. pre-run-check fails only because I have fewer than 4 merged PRs — could a maintainer add the ready label and take a look? Thanks!

[sfeng33]

Thanks for the contribution.

[sfeng33]

/ci run

[github-actions]

✅ @sungbin1015, CI is now available for this PR.

• /ci run starts upstream CI; /amd-ci run starts AMD CI only.
• Your branch must contain every commit currently on its upstream target branch. Merge or rebase onto the latest target branch, then rerun the command. Append --allow-stale to a run command to test an outdated branch at your own risk.
• /ci retry retries failed jobs in the CI build for the current PR head. If the current head has no CI build, it starts a new CI build for the current head containing only jobs that failed in the latest earlier CI build for this PR.
• /amd-ci retry retries failed jobs in AMD CI for the current PR head. Use /amd-ci run when the current head has no AMD CI build.
• /ci cancel cancels scheduled or running CI builds for this PR branch; /amd-ci cancel does the same for AMD CI only.

[github-actions]

✅ Triggered Buildkite CI #93648 for commit 4500391db11a.

[sfeng33]

/ci run --allow-stale

[github-actions]

✅ Triggered Buildkite CI #93685 for commit 459b6f2261aa.

⚠️ This PR is 11 commits behind upstream main. Running CI at your own risk because --allow-stale was requested; outdated CI configuration may cause failures. Before merging, merge or rebase onto the latest main, then rerun /ci run on the latest PR commit.