fix(serve): return the requested number of chat top_logprobs

[MohammadHijjawi97]

Motivation

/v1/chat/completions returns the wrong number of top_logprobs candidates.

For each output position, both engines return the model top-k logprobs, plus the sampled token when it falls outside the top-k (PyTorch compute_logprobs, TurboMind _get_logprobs_impl). _create_chat_completion_logprobs always removed the sampled token from top_logprobs, so:

• with top_logprobs=k, only k-1 candidates are returned whenever the sampled token is in the top-k (the same symptom as [Bug] set logprobs = true and top_logprobs = 5 in restful server. The number of top logrobs is 4 which is unexpected. #1548);
• with greedy decoding and top_logprobs=1, top_logprobs is always [];
• with logprobs=true and top_logprobs unset/0, a candidate can still be returned, because the engine is asked for 1 logprob.

The OpenAI API lists the k most likely tokens, including the sampled one when it is among them. The /generate endpoint (_create_top_logprobs) already does this.

Modification

• _create_chat_completion_logprobs takes top_logprobs. It sorts candidates by logprob, drops the sampled token only when it is the extra row appended outside the top-k, and caps the list at top_logprobs. The sampled token's own token/bytes/logprob are unchanged.
• Both the streaming and non-streaming chat paths pass request.top_logprobs or 0.
• Added tests/test_lmdeploy/serve/openai/chat_completions/test_logprobs.py. It covers the sampled token inside the top-k (k=1 and k=3), the sampled token outside the top-k, and top_logprobs=0.

pytest tests/test_lmdeploy/serve/openai/chat_completions/ passes (51 tests), and pre-commit is clean on the changed files.

BC-breaking (Optional)

No API change. Responses now contain top_logprobs entries as requested; the new parameter defaults to 0.

Checklist

1. Pre-commit or other linting tools are used to fix the potential lint issues.
2. The modification is covered by complete unit tests. If not, please add more unit tests to ensure the correctness.
3. If the modification has a dependency on downstream projects of a newer version, this PR should be tested with all supported versions of downstream projects.
4. The documentation has been modified accordingly, like docstring or example tutorials.