Make in-page viewport capture executable without a caller screenshot adapter

[chubes4]

Problem

window.wpCodeboxBrowser.v1.captureViewportScreenshot() is now exposed on main, but every production call fails with viewport_capture_unavailable unless the downstream product supplies options.browserInvoker.

The in-page WP Build consumer has a prepared Playground client but no browser screenshot implementation. Supplying one downstream would duplicate the browser-runtime mechanism that WP Codebox is intended to own and would turn the public method into persistence/verification plumbing rather than an executable capture primitive.

Current contract on main:

if ( typeof options.browserInvoker !== 'function' ) {
    return viewportScreenshotFailure( request, 'viewport_capture_unavailable', ... );
}

Reproduction

1. Start a browser preview and retain its prepared client.
2. Call captureViewportScreenshot( client, { route: '/', viewport: { width: 1280, height: 720 } } ) with the documented production defaults.
3. Observe status: failed and diagnostic code viewport_capture_unavailable.

Acceptance criteria

• The public in-page method has an owning-layer default invoker for a prepared browser preview client.
• Desktop and mobile calls produce PNG bytes, persist them through the existing Codebox artifact ability, and return immutable refs.
• browserInvoker remains an optional test/extensibility seam rather than a required product integration.
• Coverage exercises the default production path, not only an injected test callback.
• Invalid route, timeout, capture failure, persistence failure, and checksum verification continue to fail closed.

Follow-up to #2262 and #2265. Blocks launch evidence in chubes4/wp-build#1300.

AI assistance

OpenAI gpt-5.6-sol via OpenCode traced the merged public API through the WP Build consumer and identified that the required injected screenshot adapter leaves the production path non-executable. Chris Huber directed and reviews the work.