Resolve browser blueprint hydration through the WordPress REST root

[chubes4]

Problem

The canonical browser SDK treats preview_boot.blueprint_ref.hydration_endpoint as a site-root URL:

new URL( blueprintRef.hydration_endpoint, window.location.href )

WP Codebox emits the endpoint as a WordPress REST path such as /wp-codebox/v1/browser-blueprint-ref?.... On pretty-permalink WordPress this must pass through wp.apiFetch or be resolved against get_rest_url() (/wp-json/), not the site root.

Production Evidence

Found while accepting chubes4/wp-build#1274 after the canonical DTO migration in chubes4/wp-build#1277:

• authenticated canonical ref through /wp-json/wp-codebox/v1/browser-blueprint-ref?...: HTTP 200
• the SDK follow-up request to /wp-codebox/v1/browser-blueprint-ref?...: HTTP 404 HTML
• browser failure: Unexpected token '<', "<!doctype "... is not valid JSON
• the route is registered as /wp-codebox/v1/browser-blueprint-ref and get_rest_url() returns https://affectionate-multicolored-mars.wpcloudstation.dev/wp-json/

The server DTO and wp-build wp.apiFetch hydration both work. The second SDK-owned raw fetch is the failing request.

Expected Contract

Resolve REST-relative hydration paths through window.wp.apiFetch when available. Keep raw fetch for absolute URLs or an explicit REST-root-aware fallback. Add browser-runtime coverage proving a relative /wp-codebox/v1/... endpoint never becomes a site-root request.

Related

• Single preview contract for product consumers: collapse boot DTO variants, retire legacy preview paths #1743
• Unify the browser preview boot contract #2163
• https://github.a8c.com/chubes4/wp-build/issues/1274
• https://github.a8c.com/chubes4/wp-build/pull/1277

AI assistance

• AI assistance: Yes
• Model: OpenAI gpt-5.6-sol
• Tool: OpenCode
• Used for: Production diagnosis and drafting; evidence reviewed by Chris Huber.