core: support extension-owned turn items

[owenlin0]

Description

This PR adds a codex-extension-items crate for extension-owned TurnItem schemas, and updates standalone image generation to start using it via TurnItem::Extension.

This gives us a way to prevent Core from having to be aware of all extension items. App-server still exposes the existing public ThreadItem::ImageGeneration shape, now by wrapping the same shared image_generation::ImageGenerationItem type.

The new codex-extension-items crate is necessary because the image gen extension item is used by:

• codex-image-generation-extension, which produces it.
• codex-tools / core, which carry it generically.
• codex-protocol, which serializes it into lifecycle events and rollouts.
• app-server protocol, which wraps it in public ThreadItem::ImageGeneration

extension implementation
        ↓
codex-extension-items
        ↓
protocol / tools / app-server

We keep the hosted Responses API image generation as TurnItem::ImageGeneration because core still owns its persistence and legacy fanout.

Before

Standalone image generation is implemented as an extension, but its item representation previously lived in the core protocol. This sets the precedent that core is aware of all extension items, which would be good to avoid.

image-gen extension
→ constructs codex_protocol::ImageGenerationItem
→ emits ExtensionTurnItem::ImageGeneration
→ core matches ImageGeneration specially
→ protocol stores TurnItem::ImageGeneration

After

image-gen extension
→ constructs extension-owned ImageGenerationItem
→ emits generic ExtensionItem
→ core transports/persists it generically
→ app-server wraps ImageGenerationItem as ThreadItem::ImageGeneration

Future extension items can have typed app-server APIs without adding a new TurnItem variant, ExtensionTurnItem variant, or core emitter match arm.

What changed

• Added codex-extension-items with the closed ExtensionItem enum and shared image_generation::ImageGenerationItem schema.
• Added generic TurnItem::Extension(ExtensionItem) and ExtensionTurnItem::Extension { item, legacy_events } paths.
• Updated standalone image generation to emit a typed extension item and provide its existing legacy ImageGenerationBegin / ImageGenerationEnd events explicitly.
• Kept canonical lifecycle ordering: core emits ItemStarted / ItemCompleted before extension-provided legacy events.

Follow-up

Standalone web search still uses its typed special-case path. Migrating it later would let ExtensionTurnItem collapse into a single extension-item struct.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3f8b56118f

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Persist completed extension items for replay

When an extension emits a canonical item with no legacy fallback (the API allows legacy_events to be empty), this ItemCompleted(TurnItem::Extension) is delivered live but is dropped from rollout storage because rollout/src/policy.rs only keeps completed Plan/Sleep items. After resuming from that rollout, the extension-owned item is gone, so the new canonical extension item path is not durable unless every extension also invents a legacy event; include TurnItem::Extension(_) in the persisted completion policy.

AGENTS.md reference: AGENTS.md:L102-L110

Useful? React with 👍 / 👎.

[owenlin0]

no, we are purposely not doing this in this PR and deferring it for #30188 - we'll be switching to ItemCompleted(<turn_item>) for paginated threads generally then

[pakrym-oai]

should this persist TurnItem::Extension and drop legacy events?

[owenlin0]

will be doing as part of this PR! #30188