Studio Web: selectable SecEx backend to create and list sandbox sites in the browser

[lezama]

Related issues

• Builds directly on top of Studio Web: run the portable UI in a browser via a web connector and a CLI web-server command #3816 (the Studio Web foundation — this PR targets that branch, not trunk).
• Continues the broader Studio Web exploration in Studio Web (SecEx): functional sandbox sites + live client-side preview [PoC] #3746; this is the next increment extracted from it.

How AI was used in this PR

The code and this PR description were drafted with Claude Code under close direction, porting a connector that already worked in the exploration onto the cleaner foundation in #3816. I reviewed the diff, and the verification steps (typecheck across all workspaces, lint, and the full apps/ui test suite — 233 tests) were run on this branch after merging the latest base.

Proposed Changes

#3816 runs Studio's portable renderer in a browser against a local studio web-server, which can list the signed-in user's WordPress.com sites but is read-only — it can't create anything. This increment adds a second, opt-in backend that gives Studio Web its first real write capability.

The browser can now talk directly to the hosted Studio Code endpoint on WordPress.com (a SecEx sandbox), selected at build time with VITE_STUDIO_BACKEND=secex. In that mode a signed-in user can ask the agent to create a WordPress site in the sandbox and have it show up in their session list — all from a plain browser tab, no desktop app. Because this path reaches WordPress.com directly with the user's own token, it brings in a lightweight WordPress.com login screen for the browser.

The default local web-server backend from #3816 is untouched: nothing changes unless you explicitly build with the SecEx flag. Scope is deliberately narrow — create and list. A live, client-side preview of what the agent built (the "Carril A" loop from the exploration) is a separate follow-up; the connector already exposes the getSiteFiles seam that preview will consume.

This is a Proof of Concept: it lifts a ~1,200-line connector from the exploration onto the foundation to validate the "selectable backend" shape end to end. Architecture, tests, and polish would need another pass before this is merge-ready.

Testing Instructions

1. Check out this branch (based on Studio Web: run the portable UI in a browser via a web connector and a CLI web-server command #3816) and npm install.
2. Build or run the web UI in SecEx mode:
   • Dev: VITE_STUDIO_BACKEND=secex npm run dev:web --workspace=apps/ui and open http://localhost:5300.
   • The run endpoint defaults to the hosted wpcom Studio Code endpoint; override with VITE_STUDIO_SECEX_RUN_URL if needed.
3. You'll be prompted to sign in to WordPress.com in the browser (or provide VITE_STUDIO_WPCOM_TOKEN for scripted runs).
4. Send a prompt asking the agent to create a site: it provisions a site in the sandbox and the session appears in your list.
5. Confirm the default backend is unaffected: build/run without VITE_STUDIO_BACKEND=secex and the local web-server connector behaves exactly as in Studio Web: run the portable UI in a browser via a web connector and a CLI web-server command #3816.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?