fix: stop persisting the editor configuration in localStorage

[dcalhoun]

What?

Stop persisting editor configuration in localStorage.

Why?

This fallback storage was originally introduced to survive events like editor reloading. However, it became unnecessary once we ensured the configuration globals were injected for these types of events.

The persisted values could also become stale mid-session—e.g., if the media upload server stopped, the port and token would no longer be valid.

How?

Remove the localStorage set calls. Clear out existing localStorage values on editor launch.

Testing Instructions

1. iOS demo: open a post, then force a WebContent process termination (Activity Monitor → quit com.apple.WebKit.WebContent for the Simulator). The editor reloads with the current post. The demo's "Trigger Editor Crash" action is not a substitute here — it throws in JS so the error boundary catches it, leaving the page and its process intact, where this step exercises the reload that replays the document-start script.
2. Android demo: open an existing post via Browse, then rotate the device. EditorActivity declares no configChanges, so it is recreated and the editor reloads — it should render the post's saved title and content rather than the load-error view. Unsaved edits are not preserved across recreation in the demo, whose latestContent uses remember; that is unrelated to this change.
3. iOS: upgrade from a build before this change with a post open, then reopen a post. Safari Web Inspector's Storage tab for the editor page shows no GBKit key.

Accessibility Testing Instructions

N/A, no user-facing changes.

Screenshots or screencast

N/A, no user-facing changes.

---

AI-generated details

Problem

window.GBKit carries the site credential and the local server's port and token, all valid only for the load that injected them. Both platforms mirrored it into localStorage, which persists on disk across launches, and getGBKit read that copy back whenever the global was missing.

Impact

A copy of the configuration could outlive the session that issued it, and on Android it persisted under the site's own origin rather than an origin only the editor loads. #611 reads the relay's port and token through getGBKit too, so landing this first keeps a stale copy from pointing the relay at a stopped server.

Nothing needed the copy. The persisted copy arrived with the global in #14, when iOS injected the configuration with evaluateJavaScript after the page had loaded; #15 moved iOS to a document-start WKUserScript, which WebKit replays on every navigation, including the reload after a WebContent process termination. Android re-injects on every page start and wipes web storage before each load. Boot also waits for window.GBKit and, outside ?dev_mode, aborts when it never arrives, so the fallback was unreachable in production.

Mechanism

• getGBKit returns window.GBKit || {}; the storage fallback is gone.
• iOS swaps the setItem in its document-start WKUserScript for a removeItem, scrubbing an upgraded device the next time the editor loads. A test pins the script's shape.
• Android drops the setItem and the matching removeItem in clearConfig, which is now documented as teardown-only since window.GBKit is the editor's only source of configuration.
• Both CORS rationales now rest on the token alone — loopback-only, per-session, never persisted — rather than on claims about which origins or documents can read it.

Testing

make test-web-unit
make test-ios-library-simulator
make test-android-library-unit

The getGBKit test is a tripwire rather than a tautology: verified by reinstating the storage fallback and confirming the case fails.

Manual checks, each confirming the editor recovers without a persisted copy:

1. iOS demo: open a post, then force a WebContent process termination (Activity Monitor → quit com.apple.WebKit.WebContent for the Simulator). The editor reloads with the current post. The demo's "Trigger Editor Crash" action is not a substitute here — it throws in JS so the error boundary catches it, leaving the page and its process intact, where this step exercises the reload that replays the document-start script.
2. Android demo: open an existing post via Browse, then rotate the device (emulator: Ctrl+F11). EditorActivity declares no configChanges, so it is recreated and the editor reloads — it should render the post's saved title and content rather than the load-error view. Unsaved edits are not preserved across recreation in the demo, whose latestContent uses remember; that is unrelated to this change.
3. iOS: upgrade from a build before this change with a post open, then reopen a post. Safari Web Inspector's Storage tab for the editor page shows no GBKit key.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JsMCoa3jNEuvnhxicDVRBV

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/613")

_{Built from 8b27d20}