fix(tools): route Responses API memory saves through /v4/conversations

[abhay-codes07]

What

Responses API memory saves silently failed whenever a customId was configured.

The chat-completions path hands addMemoryTool the messages plus API credentials, so a configured customId routes the save through /v4/conversations (with the internal conversation: routing prefix stripped back off). The Responses path built the same prefixed memoryCustomId but passed neither messages nor credentials:

operations.push(
    addMemoryTool(client, containerTag, content, memoryCustomId, logger),  // no messages, no apiKey, no baseUrl
)

So the conversation branch never ran and the save fell through to client.add() with conversation:<id> as the stored customId — a value customId validation rejects (alphanumeric/hyphen/underscore only). Since save errors are swallowed by design (memory persistence must never break the user's API call), every responses.create call with a customId saved nothing, invisibly.

Fix

• The Responses path hands the input over as a single user message together with the credentials, mirroring the chat path — conversation grouping now works for the Responses API
• The client.add fallback strips the internal conversation: prefix so the routing marker can never leak into a stored customId on any path (the chat path had the same leak whenever SUPERMEMORY_API_KEY was unset)

Testing

• New mocked middleware tests (src/openai/middleware.test.ts): a customId save routes through addConversation with the un-prefixed conversation id and never touches client.add; the fallback stores the user's configured id, not the prefixed marker; the no-customId path is unchanged — two of the three tests fail against the previous implementation
• vitest run — 3 pass
• tsc --noEmit error count unchanged vs main (148 pre-existing), biome check clean

cc @MaheshtheDev

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.