fix(mcp-apps): let the consent message reach the toast

[philmerrell]

Follow-up to #1009, found by validating it on dev after deploy.

What #1009 fixed, and what it didn't

#1009 did what it claimed — the status and message now survive the AgentCore Runtime boundary intact:

POST /api/mcp-apps/proxy-call → 409
{"error":"Authorization required for 'google-tasks'. Connect the account, then try again."}

409, not 424, and the real message is in the body. That part is confirmed working on dev.

But the user still didn't see it. The toast read:

Conflict — The request conflicts with the current state.

Root cause

ErrorService.handleHttpError looks for a message under detail, error.detail, error.message, or message — in that order. app-api returns error as a plain string, which matches none of them (priority 2 requires error to be an object), so it falls through to createErrorMessageFromStatus and renders the generic per-status text while the real message sits unread in the body.

This also explains the pre-#1009 symptom, and it's the part worth noticing: AgentCore's 424 body used the key message, which did match priority 3. So the useless "check your CloudWatch logs" text was rendered for exactly the reason the useful text was not.

The fix

app_tool_error_body() emits the same text under both keys:

• error — McpAppProxyService reads err.error?.error and hands it to the iframe's JSON-RPC reply (unchanged behaviour).
• detail — what ErrorService actually renders, and FastAPI's own HTTPException shape, which the rest of this router already emits.

No SPA change. The fix is to speak the key the SPA already reads, rather than to teach the SPA a fifth shape.

Testing

• 2 new guards on the body shape; both relay tests now assert detail alongside error.
• Mutation-tested: dropping detail fails 4 named tests across all three files; the mutant compiles.
• 46 passed across the envelope and both route suites. ruff clean on every changed file.

Still open after this

The dev account genuinely isn't connected to Google Tasks, so the consent path is the live behaviour there — that's what made it testable. Once this deploys I'll confirm the toast reads the real message.

Unrelated and still unexplained from #1009's investigation: no POST /invocations appears in the runtime log group that serves dev, so I still can't say which of the three 409 paths fires. Worth its own issue.

🤖 Generated with Claude Code