fix: return raw base64 data instead of data URI from fetchImageAsBase64

[ishii-masaki-646]

Summary

• fetchImageAsBase64 が data:${contentType};base64,... 形式の data URI を返していたのを、生の base64 文字列を返すように修正
• MCP SDK はツール結果（type: "image"）とリソース応答（blob フィールド）の両方で、data URI ではなく生の base64 文字列を期待しているため、画像が正しく扱われていなかった

Test plan

• gyazo_image ツールで画像が正しく表示されることを確認
• gyazo_latest_image ツールで画像が正しく表示されることを確認
• リソース経由での画像取得が正しく動作することを確認

🤖 Generated with Claude Code

[fugulab]

Hit this on v0.2.0 — gyazo_latest_image and gyazo_image both come back as an error instead of an image:

MCP error -32602: Invalid tools/call result: [
  {
    "code": "custom",
    "path": ["content", 0, "data"],
    "message": "Invalid Base64 string"
  }
]

(gyazo_image throws the same thing at ["content", 1, "data"].)

It isn't client-specific. I wrote a bare stdio JSON-RPC script that does no validation of its own and got the same -32602 back, so the response is already failing inside the server process.

Setup: v0.2.0 from npm, Node 25.9.0, macOS. Same result from Claude Code 2.1.206 and from the bare script.

I then took the published build, stripped the data:<content-type>;base64, prefix off the returned string — the same edit this PR makes — and reran it. That call returns image content, and the data field decodes cleanly: base64.b64decode(s, validate=True) in Python gives back 148,141 bytes starting with 89504e47.

That was a single 148 KB PNG over stdio, decoded outside the client. I didn't try the gyazo-mcp:/// resource path, and I don't know how the compressImageIfNeeded branch behaves.

Since it looks like the same line this PR touches, I figured I'd leave it here rather than open a separate issue. Happy to re-run any of it if that's useful.