Editor load errors display raw exception text to users

[dcalhoun]

Description

When the editor fails to load, both platforms render the underlying exception message directly in the library's error view. These strings are written for developers, and they reach users of both production apps.

Examples seen in testing:

• iOS: No route was found matching the URL and request method.
• Android: rest_no_route: No route was found matching the URL and request method.
• Android: Unknown error with status code: 500
• Android: Failed to load editor; unable to resolve host…

Android additionally prefixes the machine-readable WP error code, because WPErrorResponse.message is built as "${error.code}: ${error.message}" (EditorHttpClient.kt#L85-L88).

This is not demo-only

The error views live in the library, and neither host app can override them:

• iOS: displayError renders error.localizedDescription (EditorViewController.swift#L1015-L1025). didFailToLoad is documented as firing after the error is displayed, and WP-iOS's implementation is analytics-only.
• Android: GutenbergView owns EditorErrorView and calls showErrorPhase directly (GutenbergView.kt#L373-L384). WP-Android embeds GutenbergView and inherits the view as-is.

Proposed change

• Map failure classes to user-appropriate copy rather than echoing exception text
• Auth failures: something actionable, e.g. "Sign in again to continue editing"
• Server/network failures: a generic retryable message
• Keep the raw error for logs and telemetry, not the UI
• Android: stop prefixing the WP error code in user-visible text
• Consider a retry affordance where the failure is retryable

Notes

• Editor fails to load when a cached capability flag is stale #602 removes the rest_no_route message from this view entirely, and Ambiguous request failures should degrade optional dependencies rather than fail the editor load #603 removes most transient 5xx cases under automatic fallback. What remains — auth failures, and everything under disabled fallback — still needs real copy, so this is worth doing independently and is lower priority than both.
• Pairs naturally with the typed EditorLoadFailure proposed in Ambiguous request failures should degrade optional dependencies rather than fail the editor load #603: the classification that drives host behavior can also drive the message.