dogfood: run the 3 content apps (website, docs, ui-website) on the Bun runtime

[vivek7405]

Problem

The three content apps in the monorepo (website, docs, packages/ui/packages/website) are pure SSR with NO database and NO Prisma. The framework already runs natively on Bun (the CI Bun matrix + listener parity prove it: native Bun.serve shell, ~1.9x req/s on the listening path, ~2.3x SSR vs Node, benchmarked while building #511/#517), and dev hot-reload on Bun now works (#514). So these three apps are the low-risk first movers to actually RUN webjs on Bun in our own deployments.

Design / approach

For each of the three apps, enable the Bun runtime for both dev and prod:

• Dev: bun --bun run dev (relies on dogfood: link the workspace under Bun so monorepo apps resolve local @webjsdev/* + Prisma #521 so it resolves the local workspace framework).
• Prod: a Bun deploy image + bun --bun run start. The existing Railway healthcheck wiring (/__webjs/ready via healthcheckPath) is unchanged.
• Verify each boots, serves its key routes (status < 400), and emits no broken modulepreload hints under Bun (the standard four-app boot-check, run under Bun).
• Keep Node working too; Bun is the selected runtime, not a hard cutover of the toolchain.

Depends on #521 (workspace linking under Bun). Sibling of the blog migration (the Prisma one), tracked separately because Prisma adds its own Bun risk.

Acceptance criteria

• website, docs, ui-website each boot and serve their key routes under Bun (bun --bun run start), no broken modulepreloads.
• bun --bun run dev hot-reloads a source edit for each (smoke check).
• Railway deploy config updated to the Bun runtime for the deployed content services, healthcheck still green.
• Docs updated (deployment / framework-dev) to note these apps run on Bun.
• Depends on dogfood: link the workspace under Bun so monorepo apps resolve local @webjsdev/* + Prisma #521.

[vivek7405]

Update: the apps already RUN on Bun, only the deploy switch remains

While investigating #521 I confirmed that website, docs, and ui-website all boot and serve 200 under Bun today (run from inside the repo via createRequestHandler on bun 1.3.14). The framework auto-selects the Bun.serve shell and resolves the workspace correctly, so there is no code work to "enable" Bun for them.

What actually remains is therefore narrower than this issue first implied:

• Switch each service's Railway/Docker deploy to a Bun base image + bun --bun run start (the healthcheck wiring on /__webjs/ready is unchanged).
• Optionally adopt bun --bun run dev locally (works now that Dev hot-reload of server-side modules is stale on Bun (query cache-bust ignored) #514 is in).

This is a live-infra change (it flips the deployed runtime), so it should be done deliberately and verified per service, not as a code PR. Keeping this issue open as the deploy-switch task; #521 (the supposed workspace-linking bug) is closed as not-a-bug.