fix(core): omit stale Responses Lite include

[5ocworkshop]

Summary

• remove the stale codex-lite value from the Responses API include array in both request paths
• keep the Responses Lite transport header behavior unchanged
• centralize include selection and add a regression test covering public Responses enum values

Context

Responses Lite requests with reasoning could send include[1]=codex-lite, which the Responses API rejects because it is not a public include enum value. The Lite transport signal remains in the request header.

Validation

• KEEP_ENV=0 ./build-fast.sh
• isolated CODEX_HOME live smoke with gpt-5.6-sol; returned patched-model-ok without the prior include[1] / codex-lite 400 response

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f07b6015af

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Exercise the serialized Responses Lite request in an integration test

For Responses Lite requests with reasoning, this unit test only invokes response_include_for_request directly, so it does not verify that either outbound request path serializes the corrected include array; it could remain green while the HTTP or WebSocket payload still triggers the user-facing 400 response. Add a mock-server integration test that drives the request and asserts the captured JSON contains only reasoning.encrypted_content.

Useful? React with 👍 / 👎.