fix(adapter): handle array/object content in messagesToPrompt ([object Object] bug)

[byungsker]

Problem

messagesToPrompt assumes msg.content is always a string. The OpenAI Chat Completions spec also permits content as an array of content parts for multimodal / structured messages:

{
  "role": "user",
  "content": [
    { "type": "text", "text": "hello" },
    { "type": "image_url", "image_url": { "url": "https://…" } }
  ]
}

When a client sends the array form, the existing code path (parts.push(msg.content) / \${msg.content}`) hits Array#toString→ each element's defaultObject#toString→"[object Object]"joined by commas. The Claude CLI then receives[object Object],[object Object]as its prompt and the model responds about *"receiving[object Object]` messages"* instead of answering.

Reproduction

curl -s -X POST http://localhost:3456/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer not-needed" \
  -d '{
    "model": "claude-sonnet-4",
    "messages": [{
      "role": "user",
      "content": [{ "type": "text", "text": "reply with FIXED" }]
    }],
    "max_tokens": 20
  }'

Before: Claude replies about [object Object].
After: Claude replies FIXED.

I hit this wiring the proxy into OpenClaw — its Discord/Telegram pipeline legitimately emits array-form content for every inbound user message.

Summary

• Add a contentToString(content) helper that handles the string / array-of-parts / bare-object / null cases the OpenAI spec (and real-world clients) actually emit.
• Use it in messagesToPrompt for all three roles (system / user / assistant).
• Widen OpenAIChatMessage.content to string | OpenAIContentPart[] | null so TypeScript consumers stop having to narrow manually.
• Add an OpenAIContentPart type that covers text and image_url parts, with an open-ended fallback for forward compatibility.

Behavior

Input shape	Result
"hi"	"hi" (unchanged)
[{ type: "text", text: "hi" }]	"hi"
[{ type: "text", text: "a" }, { type: "image_url", ... }]	"a\n[image]"
[{ type: "custom", foo: 1 }]	'{"type":"custom","foo":1}' (no silent drop)
null / undefined	"" (filtered before join)

Kept the [image] placeholder rather than dropping image parts entirely — the claude --print path is text-only, but losing the signal that an image was in the original message felt worse than keeping a breadcrumb.

Test plan

• npm run build — clean, no type errors.
• Manual sanity run of the built messagesToPrompt against mixed messages (string content, text-only array, text+image array, null) confirms no [object Object] in the output and each role renders as expected.
• End-to-end: same curl repro against a locally-running patched proxy returns the intended reply, not the [object Object] complaint.
• String-content requests (the existing happy path) unchanged — all three role branches still emit the same prefix/suffix wrapping.

No existing tests in the repo; I kept the diff surgical and skipped adding a test harness to avoid scope creep. Happy to follow up with a dedicated test file if you'd like.

Notes

• Upstream issues are disabled so I couldn't file one to link here — full context lives in this PR body.
• dist/ is gitignored so only the two source files are touched.