Prevent post data refetch with finishResolution instead of middleware filtering

Summary

filterEndpointsMiddleware in src/utils/api-fetch.js exists to block Gutenberg's automatic GET /wp/v2/{restBase}/{id} fetch, which overwrites the title and content injected by the native host. This middleware requires restBase and restNamespace to construct the path to block, which adds complexity to the native-to-JS bridge contract (see #432).

The root cause is that receiveEntityRecords in useEditorSetup puts post data into the store but does not mark the resolution as finished. Gutenberg's data layer treats "data exists" and "resolution is finished" as independent — so when a component calls getEntityRecord('postType', type, id), the resolver fires a network fetch even though the data is already present.

Proposed fix

After pre-seeding the post data in src/components/editor/use-editor-setup.js, call finishResolution to tell the data layer the record is already resolved:

receiveEntityRecords('postType', post.type, post);
finishResolution('getEntityRecord', ['postType', post.type, post.id]);

WordPress core uses this same pattern internally — see @wordpress/core-data/src/resolvers.js where finishResolution is called after receiveEntityRecords for navigation fallbacks and templates.

Expected outcome

• Gutenberg's getEntityRecord resolver skips the network fetch entirely since the resolution is already marked as finished.
• filterEndpointsMiddleware can be removed (or simplified), along with the JS-side dependency on restBase/restNamespace in the middleware.
• The POST_FALLBACKS constant in bridge.js may be simplified since the middleware no longer needs fallback values for path construction.

Context

• #432 added restBase/restNamespace to the Android payload and hardened the middleware with fallback defaults. That fix is correct and addresses the immediate bug. This issue tracks the deeper fix that eliminates the need for the middleware approach.
• The Android library also has hardcoded /wp/v2/posts/ paths in RESTAPIRepository.buildPostUrl() and EditorPreloadList.buildPostPath() — those are separate from this issue but related parity work (iOS already uses dynamic restBase/restNamespace for both).

Start in src/components/editor/use-editor-setup.js and compare its receiveEntityRecords flow with the finishResolution usage in @wordpress/core-data/src/resolvers.js. Then inspect src/utils/api-fetch.js and bridge.js; done means pre-seeded posts skip the getEntityRecord fetch and the middleware no longer needs restBase/restNamespace for path filtering.