refactor(mcp): serve stdio memory tools through the SDK, drop the SSE bridge

[ducnmm]

Summary

stdio @mysten-incubation/memwal-mcp already holds the delegate key, then used to open a long-lived SSE session to /api/mcp/sse and forward tools/call to the sidecar. That session is a second protocol, a second occupancy slot, and a second auth story next to the SDK — which is why Teo hits ip_active_cap, handshake 429/503, 240s “connection dropped” on a healthy /health, and bulk saves that store nothing.

This PR cuts that layer. Login/logout stay local (credentials.json, dashboard loopback). Memory tools call MemWal.create({ key, accountId, serverUrl }) the same way researcher and noter already do.

MCP client  --stdio-->  memwal-mcp
                            |
                            +-- memwal_login / logout (local)
                            +-- remember / recall / bulk / analyze / restore / health
                                    --> MemWal.create(...) --> signed REST

• No GET /api/mcp/sse, no POST /api/mcp/messages, no occupancy slot on this path.
• Relayer 401 is a retryable error. It does not wipe credentials.json.
• memwal_logout deletes the file and destroys the in-process client.
• Claude.ai Streamable HTTP /api/mcp (OAuth) is unchanged.
• Follow-up: 410 /api/mcp/sse once plugin traffic is off it.

Linear: WALM-629

Why SSE is the wrong layer here

SDK clients POST /api/remember per call. They do not have this class of bug. Community feedback on #walrus-memwal-build was the same: REST was fine; the Claude Code plugin orphaned tool calls after ~240s. Harry’s investigation of Dio’s 3–8 min saves found no slow request on the relayer — the wait was client-side handshake backoff.

Live check against relayer.memory.walrus.xyz with this branch (stdio MCP, no SSE mock):

Call	Result	Time
initialize	local	103 ms
memwal_health	ok, write_ready=true	562 ms
memwal_remember	blob on mainnet	28 s
memwal_recall	score=1.000 of that write	2.5 s
/api/mcp/sse	not opened	0

28 s remember is the write pipeline (embed / SEAL / Walrus), not the transport. That stays WALM-621. This PR only removes the session.

Test plan

• pnpm --filter @mysten-incubation/memwal-mcp test (90 pass)
• remember/recall unit tests with an SDK stub, no SSE mock
• spawn: memwal_health hits GET /health only
• live prod stdio remember → recall
• CI MCP integration job
• Do not 410 /api/mcp/sse in this PR

[nikola0x0]

Parking note — this one isn't waiting on review.

Per the internal discussion on Sep 18: we're keeping the SSE bridge for now, so the "drop the SSE bridge" half of this PR is on hold. It's backlogged together with WALM-652 (memwal_namespaces MCP tool), which is blocked on it.

@ducnmm flagging so it stops sitting in the review queue — feel free to convert it to draft whenever convenient. The SDK-backed stdio tools can come back up for review once we actually schedule the SSE cutover.

[ducnmm]

Thanks @nikola0x0 — parking this.

Keeping the SSE bridge for now; the drop-SSE half of this PR is on hold with WALM-652. I'll convert to draft so it drops out of the review queue.

SDK-backed stdio tools can come back as a smaller PR once we schedule the SSE cutover.

[ducnmm]

Closing this parked draft.

We are keeping the SSE bridge; the drop-SSE half of this change stays on hold with WALM-652. The branch was conflicting with dev and Compile & CLI Smoke was failing, so it should not sit in the open queue.

The two commits remain on this closed PR if we pick the work back up:

• 79b81a0a refactor(mcp): serve stdio memory tools through the SDK, drop the SSE bridge
• 20279829 fix(mcp): honour --relayer for this process without rewriting credentials