Support image attachments in request_user_input notes

What variant of Codex are you using?

CLI (TUI), including WSL.

What feature would you like to see?

Allow users to attach images while answering a request_user_input question through the Add notes composer.

A typical workflow would be:

1. Codex displays a multiple-choice request_user_input prompt.
2. The user selects an option and presses Tab to open Add notes.
3. The user copies an image to the clipboard and presses Ctrl+V, or pastes a local image path.
4. The notes composer inserts an [Image #1] placeholder.
5. On submission, Codex sends the selected option, textual notes, and image to the model as multimodal input.

This would help when the answer depends on visual context such as wiring diagrams, hardware photos, serial-monitor screenshots, UI mockups, error screenshots, or architecture diagrams.

Example:

Question 1/1
After the serial monitor is available, which block group should we test first?

1. LED + RGB
2. Speaker
3. Motor + Servo
4. None of the above

Add notes: [Image #1] Use the wiring shown in this photo.

Expected behavior:

• Ctrl+V while editing notes attaches the clipboard image to the current question.
• Pasting a supported local image path behaves consistently with the primary chat composer.
• Attachments are retained independently for each question when navigating backward and forward.
• Removing an image placeholder removes the corresponding attachment and relabels the remaining images consistently.
• Models without image-input support retain the existing warning behavior.
• Secret questions do not accept image attachments.

Additional information

I reviewed the current main implementation before opening this request. My current understanding of the TUI path is:

• codex-rs/tui/src/chatwidget/interaction.rs already reads clipboard images through paste_image_to_temp_png() and calls ChatWidget::attach_image().
• ChatWidget::attach_image() forwards the image path to BottomPane::attach_image().
• BottomPane::attach_image() currently attaches only when view_stack.is_empty(). A request_user_input prompt is an active bottom-pane view, so the image is not routed to its composer.
• RequestUserInputOverlay already reuses ChatComposer, and its per-question ComposerDraft already retains local_image_paths.
• The submission path currently creates ToolRequestUserInputAnswer { answers: Vec<String> }, so an attachment would also need a backward-compatible transport representation.
• Core currently returns the request_user_input result as text-only FunctionToolOutput. The existing function-call output model already supports structured InputText and InputImage content items, which may provide a natural way to return the answer JSON together with images without embedding base64 data in the textual answer.

A possible high-level approach would be:

1. Add an optional image-attachment hook to an active BottomPaneView.
2. Let RequestUserInputOverlay attach images to its existing ChatComposer and preserve them per question.
3. Add a backward-compatible attachment field to the user-input response protocol.
4. Return answer JSON plus images as structured function-call output content items.
5. Keep attachment ordering deterministic using the original question order rather than HashMap iteration.
6. Ensure image data URLs are omitted from human-readable JSON and logs.

I have not opened a pull request because the contributing guide asks external contributors to begin with an issue and unsolicited PRs are not reviewed.

Would this behavior fit the intended cross-surface design for request_user_input? If the team considers it useful, would you prefer to implement it internally, or would you be open to inviting an external PR for the TUI/core path?