fix: avoid duplicate full-size image render in user messages

[epheien]

Problem

When a user attaches an image, pi writes the attached image's path back into the user message text as a Markdown image reference (e.g. ![name.png](/abs/path/name.png)). With image blocks present, that reference was rendered a second time at full size through MarkdownBody's local-path resolver (/api/files), clipping inside the bubble's max-height — the same picture appeared twice in one user message:

1. the image-block thumbnail (clickable preview), and
2. a cropped full-size duplicate below/above the text.

Fix

UserMessageView now strips Markdown image references from the text when image blocks are present (the picture is already rendered from the blocks). When there are no image blocks, local Markdown images keep working as before.

Tests

• does not re-render the markdown image reference when image blocks exist — fails on the old code (asserts no second /api/files image), passes with the fix; red-green verified against the parent commit.
• still renders local markdown images when there are no image blocks — regression guard for the non-image-block path.
• Full MessageView.test.mjs suite: 10/10 pass; tsc --noEmit and eslint clean.

Known trade-off

When image blocks exist, all Markdown image references in the text are stripped, including ones manually written by the user (a rare case: hand-written local image reference + attached image in the same message). Since base64 image blocks don't carry the original file path, a precise "only strip the injected reference" match isn't reliably possible. Happy to refine if reviewers consider it necessary.

[epheien]

Reproduction (before the fix)

The same picture appears twice in one user message: once as the image-block thumbnail, once as a full-size image rendered from the Markdown reference pi injects into the text — cropped by the bubble's max-height:

After this fix, only the thumbnail (clickable for a larger preview) is rendered.