API errors now carry machine-readable error codes

What

• Many request/auth error branches in the API-error formatter now attach a machine-readable apiError code (and sometimes apiErrorParams) alongside the existing human-readable message. This covers tool-use concurrency conflicts, duplicate or orphaned tool_use ids, using an effort setting without thinking enabled, advisor-model incompatibility, disabled API-key auth, and provider credential failures for Bedrock, Vertex, and Foundry (which now include a remedy param).
• The catch-all error handler now classifies more failure modes with their own typed apiError codes instead of lumping them into a generic error: no_response, tls_untrusted_ca, gateway_content_type (a Bedrock proxy rewriting the event stream), provider_credentials (with apiErrorParams: {provider, remedy: 'host_managed'}), and gateway_signin_required/gateway_session_expired (with remedy: 'gateway_token' when the token came from the environment). Previously most of these produced a generic server_error/unknown message with no machine-readable cause.

Why Typed error codes let tooling and error handling react to the specific cause of an API failure instead of just showing a generic message, making it easier to tell the user what went wrong and how to fix it.