Thanks for this fix. The core change from \S+(?:[^\S\n]+\S+)*?\.<ext> to [^\n]+?\.<ext>|\S+ is a clear improvement — the original pattern couldn't handle spaces immediately before the dot extension (e.g. V1.2 .docx), and the lazy quantifier with the extension-specific lookahead keeps the match well-constrained.

A few observations:

1. Regex duplication: The extraction pattern in base.py and the cleanup pattern in stream_consumer.py are now near-identical. If the extension list diverges between the two files, media tags could be extracted but not cleaned (or vice versa). Consider extracting the pattern or extension list into a shared constant.

2. Over-matching with [^\n]+?: While the lazy quantifier + lookahead is correct here, a pathological input like MEDIA:/a/b c d e f g h i j k.pdf unwanted text here would match greedily up to .pdf and include all the intermediate text as part of the path. The lookahead prevents capturing past the extension, so this is acceptable in practice.

3. Tests cover the reported case well (CJK characters + space-before-dot). Consider also adding a test for a path with multiple internal spaces (e.g. /tmp/my file name.docx) to confirm the pattern handles repeated whitespace segments.

The fix is correct and targeted. Ship-ready with the minor maintainability note above.

Part of the MEDIA path parsing cluster: related to #26407 (spaced unicode paths from tool output), #26368 (Windows paths with spaces), #24132 (spaced file paths). This PR specifically handles the edge case of spaces before the file extension (e.g. V1.2 .docx).