feat: trigger editor savePost() lifecycle from native hosts

[dcalhoun]

What?

Adds a savePost() bridge to GutenbergKit that drives the WordPress core/editor store through its full save lifecycle. Wires it up to a "Save" button in both demo apps, which also persist post content via the WordPress REST API.

Why?

Ref CMM-2024.

Plugins that subscribe to the editor store's save lifecycle (e.g., VideoPress) rely on the isSavingPost() true → false transition to fire side-effect API calls. For example, VideoPress's useSyncMedia hook syncs metadata attributes like rating, privacy, and download settings to /wpcom/v2/videopress/meta only when it observes that transition.

In GutenbergKit today, the native host calls editor.getTitleAndContent() to read content and persists it via its own REST API call. The editor store's savePost() action is never dispatched, so plugins never see the lifecycle transition — and metadata changes silently fail to persist.

This PR exposes a savePost() bridge so the native host can drive the lifecycle before reading content for persistence, restoring plugin compatibility.

How?

Web/JS layer (src/components/editor/use-host-bridge.js):

• New window.editor.savePost() async method that dispatches editorStore.savePost().
• The existing filterEndpointsMiddleware swallows the post save HTTP request, so the lifecycle completes without duplicating the native app's persistence.

iOS library (EditorViewController.swift):

• Public savePost() async throws that uses WKWebView.callAsyncJavaScript to await the JS Promise.

Android library (GutenbergView.kt):

• Public savePost(callback) that wraps the call in a small IIFE and routes completion through the existing editorDelegate JavaScript interface (Android's WebView.evaluateJavascript cannot natively await Promises).
• Also fixes a pre-existing bug where GBKitGlobal.Post was missing restBase/restNamespace, causing the api-fetch middleware to let post fetches through and overwrite local edits.

iOS demo app:

• Adds a "Save" button to the editor toolbar that calls savePost() and then persists via posts.updateCancellation() from wordpress-rs.
• Requires Automattic/wordpress-rs#1270 to expose PostUpdateParams from the public Swift API.

Android demo app:

• Adds a PostsListActivity (mirroring iOS's PostsListView) so the user can pick an existing post to edit. Reaches the WordPress REST API through wordpress-rs's WpApiClient.
• Adds a "Browse" button beneath the Post Type picker in SitePreparationActivity that opens the posts list.
• Adds a "SAVE" button to the editor toolbar that mirrors the iOS Save flow: savePost() → read content → posts().update().
• Cleans up the editor's overflow menu to remove permanently-disabled items (Preview, Post Settings, Help, Revisions, block/word count).

Testing Instructions

This PR is best tested by editing a post that contains a VideoPress block, since VideoPress is the canonical plugin that depends on the save lifecycle for metadata sync.

Prerequisites:

• A WordPress.com (or Jetpack-connected) site with VideoPress enabled

• An existing post on that site containing at least one VideoPress block

• The site added to the demo app via OAuth¹ (WP.com) or Application Passwords (self-hosted)

• Temporarily allow the VideoPress block type:

  diff --git a/src/utils/blocks.js b/src/utils/blocks.js
  index 52a39f97..fd47f2ab 100644
  --- a/src/utils/blocks.js
  +++ b/src/utils/blocks.js
  @@ -17,7 +17,10 @@ export function unregisterDisallowedBlocks( allowedBlockTypes ) {
  
    const unregisteredBlocks = [];
    getBlockTypes().forEach( ( block ) => {
  -		if ( ! allowedBlockTypes.includes( block.name ) ) {
  +		if (
  +			! allowedBlockTypes.includes( block.name ) &&
  +			block.name !== 'videopress/video'
  +		) {
        unregisterBlockType( block.name );
        unregisteredBlocks.push( block.name );
      }
  

Steps:

1. Open the demo app (iOS or Android) and authenticate with the test site
2. From the site preparation screen, select Post as the Post Type and tap Browse
3. From the posts list, tap the post containing the VideoPress block
4. In the editor, tap the VideoPress block to select it, then open the block inspector
5. Change the Rating from its current value (e.g., G → PG-13)
6. Tap the Save button in the top-right toolbar
7. Wait for the save to complete (the button briefly disables)
8. Open the same post in the WordPress site's web editor (e.g., https://your-site/wp-admin/post.php?post=PostID&action=edit)
9. Inspect the VideoPress block — verify the Rating reflects the value you set in step 5

Additional smoke tests

• Title or paragraph edits made before tapping Save should also persist (verifies posts.update() REST call works).
• The Save button should be disabled for new drafts (postId is null) since the demo only supports updating existing posts.

Accessibility Testing Instructions

N/A, no user-facing UI changes.

Screenshots or screencast

gbk-save-post-lifecycle.mov

Footnotes

1. Certain VideoPress requests fail with when using the dev server due to CORS, use make build instead. ↩

[dcalhoun]

Superseded by #432, #433, and #435. This was split up to make testing and review easier.