Dictation becomes a Pasted text attachment that is dropped when sent to a side chat with btw

Dictated text in the chat input gets turned into a `Pasted text` attachment. When that prompt is sent to a side chat via `btw`, the attachment is not carried over, so the entire dictated message is silently lost.

### Steps to reproduce

1. Start dictation in the chat input and speak a few paragraphs.
2. The dictated text is converted into a `Pasted text #1` attachment rather than staying inline in the input.
3. Send the prompt with `btw` to start a side chat.
4. The side chat receives the attachment reference but not its content.

### Expected

The dictated content reaches the model, either inline or as a resolved attachment.

### Actual

The side chat turn arrives as a bare, unresolved reference:

```
#attachment:Pasted text #1
```

The agent has no content to read and has to ask the user to paste it again. The original dictation is not recoverable from the side chat, so a long spoken message is gone.

### Why this matters

Dictation is used for long-form input, which is exactly the length that trips the conversion to an attachment. That makes the failure most likely on the messages that cost the most to lose. The loss is also silent: the input clears and the turn is sent, so nothing signals that the content did not make it.

Two things look separable here:

- Dictation being converted to a `Pasted text` attachment at all. Paste behavior may be intentional, but for dictation it is surprising, since the user is composing rather than pasting a blob.
- Attachments not resolving when a turn is handed to a side chat. This is the data-loss half, and it would apply to any attachment, not just dictated text.

Related: #328104 (forking a chat silently drops the source provider context) is the same class of context loss across a chat boundary.

### Version

- VS Code: 1.134.0-insider
- OS: macOS 26.6.1