Closes #91. Pasting an image into a chat composer now attaches it through the same path as drag-and-drop and the file picker (`useAttachments().add`). Plain-text, URL-link and multiline paste behave as in canary 0.0.11.

- `RichText` takes an optional `onFiles`. When the clipboard holds files and no `text/plain`, the editor consumes the paste and passes any `image/*` files to `onFiles`. - `ChatComposer` passes `onFiles={attachable ? addFiles : undefined}`, the gate drop already uses. `canAttach={false}` and edit mode therefore attach nothing. - **Text wins when present.** WebKit exposes a Numbers or spreadsheet copy as `Files` + `text/plain` + `text/html`, where the file is a rendered image of the cells. These pastes keep the text. Screenshots, Finder copies and Safari "Copy Image" carry no `text/plain`, so they attach. - **Fixes raw image insertion.** On 0.0.11, pasting an image-only clipboard into a composer without attachments (the dashboard) made WebKit put a raw `<img>` into the editor DOM, outside the schema. That paste is now consumed and ignored.

### Validation

Checks ran in Ace-dev built from this branch: WKWebView shell, a disposable source host, and a real macOS pasteboard. - **Channel composer, attachments allowed:** - A PNG-only (screenshot) clipboard attached `image.png`. - A Finder-style file-URL clipboard attached `a.png`. - A non-image file was ignored. - Plain text was inserted. - A pasted URL became a link. - Multiline text kept its hard breaks, including the blank line. - A text + HTML + PNG clipboard pasted the text and attached nothing. - **Sending a pasted image end to end:** claude-opus-5-5 received the image and described the screenshot. - **Dashboard (`canAttach={false}`):** a PNG paste and a Finder-style paste inserted nothing and showed no image. Text and mixed pastes still worked. - **WebKit clipboard exposure** was confirmed with real copies in a standalone WKWebView probe: screenshot, Finder multi-select, Numbers cells, Safari "Copy Image". - **Edit mode** was checked statically only, because `apps/app` doesn't pass `editing` yet. It uses the same `attachable` gate. - `bun types` and `bun run ci` pass.

Known limits: - A Finder copy of several files exposes only the first file to WebKit, so only one image attaches. Tracked in #105. - A text + inline image copy (Notes, Pages) pastes only the text, as before. - Pasting a non-image file with attachments on does nothing and gives no feedback. Drop accepts any file and fails later.

### Built in Ace

Ace agents in Ace channels made all repository edits and ran all builds, checks and GitHub operations for this PR. The review was a separate Ace channel, and `dev-paste-validation` owned the Ace-dev and host environment. Codex supervised the work by driving the Ace Canary UI with computer use. That was the dogfooding workflow the user asked for; Codex didn't edit the repository, run builds or checks, or use GitHub for this PR.

Gaps that forced workarounds: - **#97:** a lane's Ace-dev build hit an old installed Ace-dev helper. The validation channel ran an isolated source host instead. - **#106 (tested failures):** Ace's desktop tools couldn't focus or paste into the Electrobun WebKit composer. - Point clicks were refused as occluded, element clicks didn't move focus, and background Cmd+V didn't paste. - Small Swift helpers set the pasteboard, set AX focus and pressed Edit > Paste. One CGEvent keystroke typed a stray character into the disposable draft. - **#103 (prompts and guidance):** clipboard cases were set up with `osascript` (Finder, Numbers, Safari), which raised macOS Automation prompts. Whether `desktop_key` can copy in Finder is untested; the agent skipped the tool's hint.

Other dogfooding issues found along the way: - #94: braces dropped from the timeline. - #95: a trailing colon was included in linkified URLs. - #96: the lane base and Diff tab use the project checkout's HEAD instead of origin/main.