fix(codex): add default instructions for /responses/compact

[MonsterQiu]

Summary:

• add default empty instructions for Codex /responses/compact requests
• add a regression test to verify compact requests include instructions

Why:

• /responses already injects default instructions when missing
• /responses/compact did not, which could trigger upstream 400 "Instructions are required"

Verification:

• go test ./sdk/api/handlers/openai ./internal/runtime/executor -run 'Test(OpenAIResponsesCompact|CodexExecutorCompactAddsDefaultInstructions|OpenAICompatExecutorCompactPassthrough)' -count=1\n- verified locally that /v1/responses/compact no longer fails with "Instructions are required"\n\nRelated to Codex 上下文压缩出现400的概率非常高 #2408

[gemini-code-assist]

Code Review

This pull request ensures that the 'instructions' field is present in the request body for compact executions by defaulting it to an empty string if it is missing. A new unit test was added to verify this behavior. The reviewer suggested improving the robustness of this check by also handling cases where the field is explicitly set to null, rather than just checking for its existence.

[MonsterQiu]

Updated the compact request normalization to coerce both missing and explicit null instructions values to an empty string.

Also expanded the regression test to cover both cases and re-ran:

• go test ./internal/runtime/executor -run 'TestCodexExecutorCompactAddsDefaultInstructions' -count=1\n- go test ./sdk/api/handlers/openai ./internal/runtime/executor -run 'Test(OpenAIResponsesCompact|CodexExecutorCompactAddsDefaultInstructions|OpenAICompatExecutorCompactPassthrough)' -count=1

[xkonjin]

Code Review

Simple, targeted fix with a clear regression test. No significant issues.

Correctness

• Setting instructions to "" (empty string) is the right move to satisfy the upstream 400. Just worth confirming: does the upstream API treat an empty string and a missing field identically, or does it have any behavioral difference when instructions: "" is explicitly sent? If there's a meaningful distinction (e.g., it overrides a server-side default), that should be noted.

Test Coverage

• The test covers both missing instructions and null instructions — good. Consider also adding a case where instructions is already a non-empty string, to assert that the executor does not overwrite a caller-provided value.
• The test validates the exact compact response payload with a string comparison. If the response shape ever gains additional fields, this will break. Asserting specific fields (id, object) rather than the full JSON string would be more resilient.

Scope

• This fix is isolated to executeCompact. Does the same instructions injection logic apply to the standard Execute path, or is it already handled there separately? If it is handled elsewhere, a brief comment cross-referencing that would avoid future confusion.