[Bug]: unsupported-media Base64Source tool results write a new undeleted temp file with a new random path on every reformat

### Prerequisites

- [x] I have searched the existing issues and discussions, and this is not a duplicate.
- [x] This is a bug, not a usage question.

### Background / Description

`FormatterBase.convert_tool_result_to_string` saves an unsupported-media-type
`Base64Source` tool result to a temp file so its path can be shown to the model.
`format()` re-serializes the same, unchanged message history on every LLM call in a
conversation, so calling it twice on the same tool result block should produce the same
output. Instead, the Base64Source branch writes a brand-new file with a brand-new random
path on every single call, using `tempfile.NamedTemporaryFile(..., delete=False)`. Two
problems follow: the text shown to the model differs between calls even though nothing
changed (defeating provider-side prompt/prefix caching, same class of bug fixed for the
promoted-block identifier path in #2165), and the files are never cleaned up anywhere in
the codebase, so a long-running agent with unsupported-media tool results accumulates one
new file on disk per reformat.

### Error Messages

N/A - not an exception, a silent correctness/resource issue.

### Steps to Reproduce

```python
import asyncio
from agentscope.formatter import OpenAIChatFormatter
from agentscope.message import DataBlock, Base64Source

fmt = OpenAIChatFormatter()
block = DataBlock(
source=Base64Source(data="ZmFrZSBwZGYgZGF0YQ==", media_type="application/pdf"),
)

first_text, _ = fmt.convert_tool_result_to_string([block])
second_text, _ = fmt.convert_tool_result_to_string([block])

print(first_text == second_text) # False: two different temp-file paths
```

Run twice on the unchanged `block`, `first_text` and `second_text` embed two different
paths (e.g. `/tmp/tmpvrf8oo37.pdf` vs `/tmp/tmp8d6daa2q.pdf`), and both files remain on
disk afterwards.

### Environment

- AgentScope Version: 2.0.5
- Python Version: 3.11
- OS: Linux (reproduced in a clean `python:3.11-slim` Docker container)