bug: user-facing error discards the provider's reason, only shows "Provider returned error"

Issue に記載されているチャットタスクのエラーハンドリング経路から始め、プロバイダーのレスポンスがどのようにメッセージエラーと UI バブルのテキストになるかを追跡します。error.metadata.raw と汎用の error.message の処理を確認します。完了の条件は、プロバイダーの理由が存在する場合に、ユーザー向けのエラーにそのまま対処に使えるプロバイダーの理由が含まれていることであり、auto-retry の動作は対象にしません。

When an upstream provider fails, OpenRouter returns a structured error with the real reason in error.metadata.raw. Example from a live failure:

{"error":{"message":"Provider returned error","code":429,"metadata":{"raw":"z-ai/glm-5.3-flash is temporarily rate-limited upstream. Please retry shortly, or add your own key to accumulate your rate limits: ...","provider_name":"BaseTen","limit_source":"upstream_provider_shared_pool","remedy_hint":"Retry shortly, add your own provider key, or route to another provider"}}}

The chat task's error handling reads only error.message and stores that as the message error. So the chat shows:

Error: Provider returned error

That string carries zero actionable information: no rate limit, no provider name, no retry hint. The user cannot tell a transient 429 (retry in a minute) from a dead API key (needs settings) from a model outage (switch model). The full reason was in the response body and got dropped on the floor.

Suggested change: when building the error message, prefer error.metadata.raw over error.message when the message is the generic "Provider returned error" (or more generally, include the raw reason whenever metadata is present). Same for the error the user sees in the UI bubble.

Related: #188 asks for auto-retry on 429, which is a separate ask; this issue is only about surfacing the actual reason when the error is shown. #178 was an earlier report where the error stayed invisible.