TUI: clipboard image paste for text-only models saves the PNG, then discards its path — insert the path as text instead

Summary

When the active model does not advertise image input, pasting a clipboard image in the TUI writes the image to a temp file and then throws the path away, leaving only a warning. Every neighboring code path in the same situation preserves the path as plain text. Making the clipboard-paste branch do the same would let text-only models (paired with vision-bridge tooling) keep working, with a very small change.

Current behavior (rust-v0.149.1)

1. Ctrl+V with an image on the clipboard always writes a temp PNG first: paste_image_to_temp_png() creates codex-clipboard-*.png before any modality check (clipboard_paste.rs#L121).
2. attach_image then checks current_model_supports_images(); when false it emits a warning and returns, discarding the freshly saved path (chatwidget/interaction.rs#L204). The file stays on disk; its path survives only in debug logs.

Inconsistency with neighboring paths

• Pasting an image file path (rather than a bitmap) into the composer with a text-only model falls through to insert_str, so the path is kept as plain text (chat_composer.rs#L1151).
• Core request assembly for text-only models also preserves the path: strip_images_when_unsupported replaces only the InputImage pixels with a placeholder, while the <local_image [Image #N] path="..."> text tag survives (context_manager/normalize.rs#L317, protocol/models.rs#L1739).

So the design elsewhere is consistently "no pixels for text-only models, but keep the path as text". The TUI clipboard-paste branch is the one place that drops it.

Proposed change

In attach_image's unsupported branch, insert the already-saved temp path into the composer as plain text (same treatment as a pasted image file path), optionally keeping the existing warning. No request-level changes needed: core already strips pixels for text-only models.

Why it matters

Users on text-only models increasingly pair Codex with vision-bridge skills/tools that read an image from a path appearing in the conversation. Today the same user action (Ctrl+V) works in flows where the path label survives, but dead-ends in the TUI even though the bytes are already on disk. Reference report: https://github.com/liustack/modlens/issues/78

Suggested test coverage

• Text-only model + clipboard bitmap → composer contains the temp PNG path as text; submitted request contains no input_image.
• Image-capable model keeps the current attachment behavior.
• Paths with spaces; WSL (PowerShell fallback already returns a converted path).

Start in codex-rs/tui/src/chatwidget/interaction.rs at attach_image's unsupported-model branch, then compare the path handling in codex-rs/tui/src/bottom_pane/chat_composer.rs. Verify the suggested text-only and image-capable clipboard cases, including paths with spaces and WSL; done means the temp PNG path remains in the composer while submitted requests contain no input_image.