fix(context_compaction): charge inline base64 tool-result images at flat image cost - #29818

Summary

_estimate_messages_tokens charged a message's files list through _estimate_tokens, which JSON-serializes the value and counts len // 4. Tool-result images are persisted inline as base64 data URIs, so this counted the entire base64 payload as text tokens.

For a single ~3 MB image (≈ 4,197,680 base64 chars) this produced a ~1,049,420-token estimate for one message — larger than the backend's whole KV pool — and fired spurious auto-compaction even though engine-side prompt tokens stayed normal.

This PR:

• charges files entries that carry a data: image URI with the flat image cost already used for content images (image / image_url → 1000 tokens), and
• strips any remaining inline base64 data URIs from other file fields so their payload is not counted as text.

Why

Reported in #29761. #29765 fixes the model-facing leak (middleware.py extract_base64_images) but leaves this estimator charging the same base64 via files, so the spurious compaction and inflated context meter persisted.

How I verified

Standalone reproduction using the reported scenario (one files entry with a ~4,197,680-char base64 data URI):

• before: 1,049,438 tokens
• after: 1,000 tokens (flat image cost); non-image data URIs are stripped before counting.

Notes

• Only backend/open_webui/utils/context_compaction.py is touched.
• No overlap with fix: store tool result images as file references #29765 (files.py, middleware.py).