macOS: Ctrl+V image paste fails when clipboard contains raw image data (no file-url)

### Describe the bug

## Summary

Ctrl+V image paste is a no-op on macOS when the clipboard contains raw image data (e.g., copied from SnagIt, Preview.app) rather than a file reference. Drag-and-drop of image files works correctly.

## Environment

- macOS 15
- iTerm2 3.5.x
- Copilot CLI v1.0.67

## Reproduction

| Clipboard source | Paste method | Result |
|---|---|---|
| SnagIt Editor → Copy (⌘C) | Ctrl+V | ❌ No-op |
| Preview.app → Copy image (⌘C) | Ctrl+V | ❌ No-op |
| PNG file in Finder | Drag into terminal | ✅ Image attaches |

## Pasteboard Evidence

With an image copied from Preview (no file selected in Finder):

```
$ osascript -e 'tell application "System Events" to get (clipboard info)'
«class PNGf», 42574, «class AVIF», 18000, «class 8BPS», 216588, GIF picture, 20509,
«class jp2 », 48749, JPEG picture, 61081, TIFF picture, 911524, «class BMP », 908186, «class TPIC», 116549

$ osascript -e 'try' -e 'the clipboard as «class furl»' -e 'on error e' -e 'return e' -e 'end try'
→ "Can't make the clipboard into type «class furl»."
```

Raw image data is present in multiple formats but **no `furl` (file URL) pasteboard type exists**.

## Root Cause (Hypothesis)

The CLI's Ctrl+V paste handler resolves `public.file-url` pasteboard entries only. When an image is copied from an editor (not a file in Finder), the pasteboard contains raw image bytes without a file reference. When this happens, the handler finds no URL and silently drops the paste.

Drag-and-drop works because iTerm2 emits the file path as text, which the CLI resolves to an image file.

## Suggested Fix

On macOS, when Ctrl+V finds no  public.file-url  on the pasteboard, fall back to reading `public.png`/`public.tiff` directly (via `NSPasteboard`, the `pngpaste` utility, or an equivalent), write to a temp file, and attach as an image; the same path drag-and-drop already exercises.

```bash
osascript -e 'the clipboard as «class PNGf»' > /tmp/clipboard-image.png
```

Then attach the temp file as an image.

## Related Issues

- #1276 — general image paste support request
- #3104 — closed as "Ctrl+V works" but does not cover this raw-data scenario

### Affected version

1.0.67 (1.0.68 released day of discovery/filing but not tested)

### Steps to reproduce the behavior

## Reproduction Steps

1. Open Copilot CLI in iTerm2 on macOS 15.
2. In Preview.app (or any image editor — SnagIt, Photos, Screenshot.app), open an image.
3. Copy the image to the clipboard (⌘C, or right-click → Copy).
4. Return focus to the Copilot CLI terminal window.
5. Press to paste.

### Expected behavior

**Expected:** The image attaches to the current prompt, same as dragging a PNG file into the terminal.

**Actual:** Nothing happens. No attachment, no error message, no visible feedback of any kind.

## Contrast Case (works correctly)

1. In Finder, select a PNG file.
2. Drag it into the Copilot CLI terminal window.

**Result:** Image attaches correctly. This confirms the image-attachment code path works end-to-end; the bug is specifically in the clipboard-paste path when the pasteboard contains raw image data rather than a `file-url` reference.

### Additional context

_No response_

Start by locating the macOS Ctrl+V paste handler and compare it with the existing drag-and-drop image attachment path. Reproduce with Preview.app or SnagIt and inspect the pasteboard formats shown in the issue. Done means raw image clipboard data attaches as an image without regressing file-url paste or drag-and-drop.

Written by the indexing model from the issue text.