Image attachment sent to a non-vision model permanently locks the chat

## Summary
Sending an image attachment to a model that does not support image input fails with provider's 400. Subsequent requests in the same chat replay the image on every request, effectively locking the chat.

## Example error:
```
400: {"message":"this model does not support image input (ref: ...)","type":"invalid_request_error","param":null,"code":null}
```

## Steps to reproduce
1. Add a model that does not support image input (e.g. GLM-5.2)
2. Start a chat with that model suggested, attach and image and send a message. Upload validation will accept it, but request will fail with a 400 (as above).
3. Send any follow-up message in the same chat - no attachment this time.
4. *Bug*: the new requests will fail.

## Suggested Fix
### Primary
Stop re-sending images the model can't accept. When the agent rebuilds the message history for a request, check whether the current model supports image input, if it doesn't, don't include the image bytes; instead replace the image with a short text note like [Attached file photo.png (image/png) omitted — this file type is not supported by the current model].

### Secondary
Reject the upload up front. We should reject images being uploaded if the selected model does not support images (alternate — some sort of warning). This is a nice-to-have, but the primary fix would actually make it so that we both unstick chats AND allow multi-model chats with some image models and some non-image models to work well.

Start at the agent logic that rebuilds message history for each request, then reproduce the listed image-upload and follow-up steps with a non-vision model. Done means the initial failure does not permanently lock the chat: later requests omit unsupported image bytes or show the specified text note, while chats can switch between image-capable and non-vision models.

Written by the indexing model from the issue text.