dogfood: link the workspace under Bun so monorepo apps resolve local @webjsdev/* + Prisma

[vivek7405]

Problem

After the dev hot-reload fix (#514), I tried running the in-repo apps under Bun (bun --bun run dev / start) and hit a resolution divergence: Bun resolves @webjsdev/* and @prisma/client from its OWN global install cache (~/.cache/.bun/install/cache/...) instead of the npm-linked workspace node_modules. Concretely, booting examples/blog under Bun loaded @webjsdev/server@0.8.27 from the Bun cache (not the workspace 0.8.28), and @prisma/client@7.8.0 from the Bun cache (not the npm-installed 5.22.0 with the generated client). A stray bun install had created a parallel, divergent dependency tree.

The effect: running the monorepo apps under Bun exercises STALE PUBLISHED packages, not the local framework, which defeats dogfooding (and crashed on an old un-guarded module.registerHooks seed-hook path that the current 0.8.28 already guards). This is the prerequisite for any Bun-app work: until Bun resolves the workspace, every Bun run is testing the wrong code.

Design / approach

Make the monorepo Bun-install-aware so a bun run resolves the LOCAL workspace packages (and the generated Prisma client) the same way npm does:

• Confirm the root package.json workspaces are honoured by bun install (Bun supports workspaces; the divergence suggests an app-level bun install ran instead of a root one, or Bun’s isolated-cache linking needs configuring).
• Decide the policy: either a committed Bun lockfile/workspace setup alongside npm, or a documented bun install flow at the repo root that links @webjsdev/* to the workspace.
• Keep npm as the primary toolchain (no npm regression); Bun support is additive.

Acceptance criteria

• A documented bun install (or equivalent) at the repo root links every @webjsdev/* workspace package so a Bun run resolves the local source, verified by booting an app under Bun and asserting the resolved path is under packages/, not ~/.cache/.bun.
• The Prisma client resolves from the app node_modules (generated copy), not the Bun global cache.
• Documented in agent-docs/framework-dev.md (monorepo Bun dev) and/or AGENTS.md.
• Blocks dogfood: run the 3 content apps (website, docs, ui-website) on the Bun runtime #522 and dogfood: verify and enable Prisma-on-Bun so examples/blog runs on the Bun runtime #523 (the app migrations depend on this).

[vivek7405]

Finding: this is not a real bug, the apps already resolve the workspace on Bun

I traced the resolution divergence that prompted this issue and it was a probe artifact, not a monorepo problem. I had booted the apps from a throwaway script in /tmp, which is OUTSIDE the repo, so Bun's auto-install kicked in and pulled @webjsdev/server and @prisma/client from its global cache (~/.cache/.bun/install/cache/...) instead of the workspace. Run from inside the repo (the way the apps actually run), Bun resolves correctly:

• import.meta.resolve('@webjsdev/server') from both the repo root and examples/blog returns packages/server/index.js (the workspace, 0.8.28 with the Bun seed-hook guard), not the cache.
• @prisma/client resolves to the npm-installed 5.22.0 with its generated client.

All four in-repo apps boot and serve 200 under Bun when run from the repo: website, docs, ui-website, and the Prisma-backed blog home page (a real DB read). The framework's module.registerHooks seed-hook correctly no-ops on Bun, no crash.

So there is nothing to fix here: the npm workspace hoist already gives Bun the local packages, because Bun walks up the directory tree for node_modules like Node does. The only gotcha is a self-inflicted one (running a loose script from /tmp), which the repo's own boot-check guidance already warns against. Closing as not-a-bug. The dogfood value lands on #522 / #523 instead, which I am updating with these results.