Editor load errors display raw exception text to users

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

• #602 removes the rest_no_route message from this view entirely, and #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 #603: the classification that drives host behavior can also drive the message.

Start with displayError in ios/Sources/GutenbergKit/Sources/EditorViewController.swift and EditorErrorView/showErrorPhase in android/Gutenberg/src/main/java/org/wordpress/gutenberg/GutenbergView.kt. Review EditorHttpClient.kt lines 85–88 and the relationship to the typed EditorLoadFailure proposed in #603. Done means both platforms show user-appropriate auth or retryable messages while raw details remain available for logs and telemetry.