Add a Bun boot-check in CI for website, docs, and ui-website

[vivek7405]

Problem

All 4 in-repo apps deploy on Bun in production, but only examples/blog has Bun coverage in CI (the blog-on-bun e2e from #523/#525). website, docs, and packages/ui/packages/website only get a NODE boot-check, so a per-route break that occurs only on Bun can reach production undetected.

This is not hypothetical: the #526 incident was exactly this class. ui.webjs.dev served 500s on its component detail pages in production. Railway's deploy gate (/__webjs/ready) did not catch it because that healthcheck is liveness-only and never probes individual routes. A CI step that boots those three apps on Bun and GETs real routes would have caught it before deploy.

Design / approach

Add a Bun boot-check for website, docs, and packages/ui/packages/website to the CI Bun job (the matrix already runs node scripts/run-bun-tests.js + the test/bun/*.mjs scripts on Bun). Reuse the existing prod boot-check harness shape (boot each app via createRequestHandler({ dev: false }), GET a few real routes, assert status < 400, and assert no modulepreload hint 404s, the #158/#159 probe), but run it under Bun rather than Node.

• Probe REAL routes, not just / and not just the liveness /__webjs/ready. For ui-website specifically, include a component detail page (e.g. /docs/components/progress), since that is the exact route class that broke in dogfood: bake the ui-website registry into the deploy image (Bun serve 500s without it) #526.
• Run from inside the repo so the bare @webjsdev/* specifiers resolve from the workspace (the in-repo boot-check already does this on Node).
• Keep the blog on its existing bun e2e (no duplication); this issue covers the OTHER three apps.
• This is the in-repo-app analog of the per-PR "Dogfood four-app" gate, extended to the Bun runtime the apps actually deploy on.

NON-GOALS: not converting the apps' local scripts or lockfiles to Bun (they are npm-workspace members that resolve @webjsdev/* via symlink to HEAD; a per-app bun install would break that, see #541's non-goals). This is CI-only.

Acceptance criteria

• CI boots website, docs, and ui-website on Bun and GETs real routes (incl. a ui-website component detail page), failing the job on a status >= 400 or a broken modulepreload.
• The check runs in the existing CI Bun job and resolves @webjsdev/* from the workspace.
• A counterfactual confirms the check actually fires (e.g. it would fail against the pre-dogfood: bake the ui-website registry into the deploy image (Bun serve 500s without it) #526 ui-website state, where a component page 500'd on the bun/deploy path).
• The blog's existing bun e2e is left as-is (no duplicate coverage).
• Docs / agent-docs/testing.md + the relevant AGENTS.md note the new Bun app boot-check.

Implementation notes (where to edit + the #526 landmine)

• CRITICAL, the dogfood: bake the ui-website registry into the deploy image (Bun serve 500s without it) #526 root cause: ui-website's predev / prestart run node scripts/copy-registry.js (prestart also runs css:build) to copy components from @webjsdev/ui-registry into the app. The dogfood: bake the ui-website registry into the deploy image (Bun serve 500s without it) #526 break was the bun prod start bypassing prestart, so the registry was absent and the component pages 500'd with "Cannot find module .../accordion.ts". A boot-check that boots ui-website via createRequestHandler MUST run node scripts/copy-registry.js (plus the css build) FIRST, mirroring the Dockerfile bake, or it reproduces the exact same 500. website and docs have no such prestep.
• CI lives in .github/workflows/ci.yml, which already has a bun: job (around L84, using oven-sh/setup-bun@v2) that runs bun test/bun/*.mjs scripts (smoke, listener, file-storage). Add a bun test/bun/app-boot.mjs step plus that script.
• The script boots website, docs, and packages/ui/packages/website via createRequestHandler({ dev: false }), runs from the repo root so the bare @webjsdev/* specifiers resolve from the workspace, GETs real routes (for ui-website include /docs/components/progress, the dogfood: bake the ui-website registry into the deploy image (Bun serve 500s without it) #526 route), and asserts status < 400 plus no broken same-origin modulepreload hrefs (the Modulepreload hints emitted for server-only files the gate 404s #158 / Import scanner counts imports shown as code inside template literals #159 probe).
• Leave examples/blog as-is (its bun e2e from dogfood: verify and enable Prisma-on-Bun so examples/blog runs on the Bun runtime #523 / test: run the blog e2e against a Bun-served blog (#523) #525 already covers it).
• Prior art for the harness shape: the per-PR Dogfood four-app boot-check snippet (boots each app, probes preloads) in the webjs-start-work flow, run here under bun instead of node.