feat(openai): expose completion token IDs in chat completion responses

[DavidBellamy]

Summary

Add an opt-in mechanism to return the worker-emitted completion token IDs alongside the chat completion response, so callers can avoid re-tokenizing the assistant's reply when they need exact token sequences (e.g. multi-turn conversations where the next prompt is built from prior tokens, or training pipelines that record rollout token streams).

Three small additions to the OpenAI chat-completion entrypoint:

1. ChatCompletionRequest: new return_completion_token_ids: bool = False request field.
2. ChatCompletionResponseChoice: new completion_token_ids: Optional[List[int]] = None response field. Omitted from JSON when null (consistent with the existing prompt_token_ids / hidden_states fields).
3. serving_chat._build_chat_response: extracts output_ids from the worker ret_item and populates the new field when the flag is set.

Plus tests covering serialization of both fields.

Why

When the application layer needs the exact token IDs the model emitted (not the detokenized string), there's currently no way to get them through the chat completion endpoint without enabling `return_meta_info` and parsing free-form metadata, or re-tokenizing the response text on the client. The latter can diverge from what the model actually emitted, especially for multimodal or special-tokenized content.

This mirrors the existing `return_prompt_token_ids` / `prompt_token_ids` pair on the request side, keeping the API surface symmetric.

Constraints

• The flag rejects streaming (`stream=true`) with a clear `ValueError`, matching the existing `return_prompt_token_ids` behavior.
• Default is `false`; existing callers see no change.
• No new dependencies, no worker-side changes (IDs already on `ret_item["output_ids"]`).

Test plan

• Unit tests for `ChatCompletionRequest` accepting the new flag and `ChatCompletionResponseChoice` round-tripping the field.
• Streaming-incompatibility check raises `ValueError`.

Provenance

This is one of five focused PRs that supersede #3. The remaining pieces of #3 land in their own PRs:

• mooncake_transfer_engine.py ibv_reg_mr concurrency lock
• http_server.py tokenizer_sha256 endpoint
• server.rs Miles `/add_worker` shim
• router.rs TITO debug logging