🪲 BUG-#3: Fix image attachments always sent as image/png

[FernandoCelmer]

Description

Fix image attachments always being sent as image/png regardless of actual MIME type.

addPendingImageFile() was stripping the data:<mime>;base64, prefix from FileReader.readAsDataURL()'s result, keeping only the bare base64. Both the attachment preview and addUserTurn's history rendering then hardcoded data:image/png;base64, when reconstructing it. JPEG/GIF/WebP attachments were mislabeled as PNG everywhere, including in the images array forwarded to pycodeloop serve.

Now the full data URL (real MIME included) is kept end to end — pushed into pendingImages as-is, used directly as img.src, and sent through sendPrompt's images array unchanged. addUserTurn still accepts a bare base64 string (assumes PNG) for sessions saved before this fix.

Motivation and Context

Closes #3

Paired with dotflow-io/pycodeloop#12 — pycodeloop's own _shapes.py also hardcoded image/png in the outgoing API request, so both sides needed the fix for it to work end to end.

Types of changes

• Bug fix
• New feature
• Documentation

Checklist

• Self-review done
• Tests added
• CHANGELOG updated
• Docs updated

Test plan

• npm test (37 passed) / npx tsc --noEmit / npm run lint clean

[FernandoCelmer]

The fix is clean and correct.

Root cause addressed: addPendingImageFile was stripping the data:<mime>;base64, prefix via .split(',')[1], causing downstream code to reconstruct it with a hardcoded image/png MIME type. The PR removes that stripping at the source and propagates the full data URL throughout, which is the right approach.

Backward compatibility: The ternary in addUserTurn (image.startsWith('data:') ? image : 'data:image/png;base64,' + image) correctly handles sessions persisted before this fix -- bare base64 strings still render as PNG, matching old behavior.

Guard correctness: dataUrl.startsWith('data:') is a reasonable guard since FileReader.readAsDataURL() always returns a data URL per spec; it is semantically tighter than the previous truthiness check and safe.

No blocking issues found. Changes are minimal, focused, and consistent with the described fix.