[codex] Add streaming image previews and proxy deploy fixes

[AkideLiu]

Summary

• Adds streaming image preview support for OpenAI-compatible Images API and Responses API calls.
• Parses SSE partial-image events from images/generations, images/edits, and responses, while keeping a JSON fallback for providers that ignore streaming.
• Shows transient partial previews in task cards and the detail modal while generation is running.
• Adds a 流式图片预览 setting, URL import/export support, and defaults streaming previews to enabled for OpenAI profiles while preserving explicit opt-out.
• Extends the mock image API and tests to cover streaming Images API and Responses API paths.
• Updates the Docker Nginx proxy for Cloudflare-backed API proxy targets by enabling TLS SNI, disabling proxy buffering for streamed API responses, and setting Referrer-Policy: unsafe-url for iframe embedding cases that need full referrer forwarding.

Related issues

• Refs 耗时超出 01:00 图片生成失败 #7: long image generation requests timing out or failing after roughly one minute. Streaming previews keep the request active and show progress when the upstream supports partial images.
• Refs 【反馈】无法使用 sub2api 的接入 #33: sub2api / proxy / CORS failures. The Nginx SNI change fixes TLS handshakes for Cloudflare-backed proxy targets without hard-coding any provider endpoint.

Cloudflare timeout notes

• Cloudflare documents Error 524 as the origin accepting the connection but not sending a timely response before the default 120 second Proxy Read Timeout.
• Cloudflare connection limits list Proxy Read Timeout as 120 seconds, returning 524, configurable only for Enterprise zones.
• OpenAI image streaming emits partial image events with base64 image data. This PR forwards those SSE chunks through Nginx without proxy buffering, so Cloudflare sees response bytes while long image generation is still running.
• This mitigates Cloudflare timeout limits when the upstream emits streaming events before the read-timeout window. A completely silent upstream request that sends no bytes for longer than Cloudflare's timeout can still 524 and needs DNS-only routing, Enterprise timeout tuning, polling, or another asynchronous flow.

Docs:

• Cloudflare 524: https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-524/
• Cloudflare connection limits: https://developers.cloudflare.com/fundamentals/reference/connection-limits/
• OpenAI image streaming events: https://developers.openai.com/api/reference/resources/images

Implementation details

• Images API streaming handles image_generation.partial_image, image_edit.partial_image, image_generation.completed, and image_edit.completed events.
• Responses API streaming handles response.image_generation_call.partial_image, response.completed, and response.output_item.done image outputs.
• Running tasks store partial previews separately from completed results so aborted, failed, or completed tasks clear the transient preview state correctly.
• Streaming is enabled only when streamImages is true; FAL/custom provider defaults remain non-streaming.
• If a provider returns normal JSON instead of text/event-stream, the existing non-streaming parser is used.

Validation

• npm test
• npm run build
• docker build -f deploy/Dockerfile -t gpt-image-playground:pr-50 .
• Container Nginx render/header checks were run locally for the deploy image.

[CookSleep]

没有别的意思，但是你自己测试完，真的觉得这个有用吗？我之前测试了自己的 Plus 号 Codex 放到 CPA 进行流式传输，官方那个 SSE 事件太少了，间隔还特别长，感觉完全不能缓解这个情况，最后还是靠 CPA 自己的那个非流式的 Keep Alive，我设置成 30 秒以后就好了。但问题是，New API 好像不是很愿意加这种功能。

然后这个中间过程图像获取还会收钱。

[AkideLiu]

没有别的意思，但是你自己测试完，真的觉得这个有用吗？我之前测试了自己的 Plus 号 Codex 放到 CPA 进行流式传输，官方那个 SSE 事件太少了，间隔还特别长，感觉完全不能缓解这个情况，最后还是靠 CPA 自己的那个非流式的 Keep Alive，我设置成 30 秒以后就好了。但问题是，New API 好像不是很愿意加这种功能。

然后这个中间过程图像获取还会收钱。

我测试之后能解决cloudflare 120s超时的问题。我是对接sub2api测试的，效果比较理想。中间状态在sub2api上看到不会收费

[CookSleep]

没有别的意思，但是你自己测试完，真的觉得这个有用吗？我之前测试了自己的 Plus 号 Codex 放到 CPA 进行流式传输，官方那个 SSE 事件太少了，间隔还特别长，感觉完全不能缓解这个情况，最后还是靠 CPA 自己的那个非流式的 Keep Alive，我设置成 30 秒以后就好了。但问题是，New API 好像不是很愿意加这种功能。
然后这个中间过程图像获取还会收钱。

我测试之后能解决cloudflare 120s超时的问题。我是对接sub2api测试的，效果比较理想。中间状态在sub2api上看到不会收费

那你是设置了多少张中间图像呀？

[AkideLiu]

那你是设置了多少张中间图像呀？

这个是由官方接口里面的partial image 决定的，一般是0-3张这样吧。

具体可以参见：https://developers.openai.com/api/docs/guides/image-generation?api=responses

You can adjust the partial_images parameter to receive 0-3 partial images.

下面是测试结果，套了CF Tunnel和Cloudflare

轻松生成3:20s的图片：

我查看了一下SSE response里面的Ping的频率还是很高的：

[CookSleep]

那你是设置了多少张中间图像呀？

这个是由官方接口里面的partial image 决定的，一般是0-3张这样吧。

具体可以参见：https://developers.openai.com/api/docs/guides/image-generation?api=responses

您可以调整 partial_images 参数以接收 0-3 张局部图像。

下面是测试结果，套了CF Tunnel和Cloudflare

轻松生成3:20s的图片：

额我意思是你自己设定的，因为我当时设定1张感觉完全没有用，算了，我晚上再测试吧

[AkideLiu]

我查看了一下SSE response里面的Ping的频率还是很高的：

除了partial_image还会放回ping值，也就是图中的：

[CookSleep]

我查看了一下SSE response里面的Ping的频率还是很高的：

除了partial_image还会放回ping值，也就是图中的：

啊？官方还会返回这个吗？难道是 CPA 在我测试时吞掉了？我晚上做的时候再看一下。不过可能合并还得上一点时间，因为正在做 Agent 模式。

[CookSleep]

我查看了一下SSE response里面的Ping的频率还是很高的：

除了partial_image还会放回ping值，也就是图中的：

我借到了一个朋友的OpenAI API官方key开Image API的流式测试，发现无论是否请求中间步骤图像，都是没有Ping的……主要还是靠中间步骤图像事件维持连接，和之前的结论差不多。

那基本上只能请求多一点中间步骤图像了。