Add Eve (durable AI agents) to the stack — an agent tier for next-forge

Is your feature request related to a problem? Please describe.

next-forge covers the model-call tier through packages/ai (AI SDK), but has no story for the agent tier — durable, tool-using backend agents. Eve (Vercel's open-source agent framework) defines exactly that shape, and a next-forge monorepo is where it shines: agent tools can reuse the same workspace packages, Prisma schema, and validated env keys the apps already use.

Today, users wiring Eve into a next-forge project hit several undocumented seams. I built and verified the integration end-to-end on a fresh [email protected] scaffold (pnpm) with [email protected], and found:

1. eve init . mutates the workspace root — rewrites root engines.node (>=18 → 24.x, Eve's hard minimum) and appends a dependency-hygiene block to pnpm-workspace.yaml. Surprising if undocumented.
2. server-only guards block agent runtimes — @repo/database's root entry (and other packages') carries import "server-only", which only the Next.js runtime satisfies. Eve agents run on Nitro, so direct imports crash at boot. Workaround: import @repo/database/generated/client + @repo/database/keys directly.
3. Tools must bundle to a single module — dynamic import() inside a tool fails Eve's build.

With those documented, the integration works cleanly: durable sessions with tool calls against @repo/database, graceful degradation when DATABASE_URL is absent (matching next-forge's optional-integration philosophy), eve build, typecheck, and eve eval --strict all green.

Describe the solution you'd like

An addon guide — docs/content/docs/addons/eve.mdx — following the existing addon shape (c15t, Trunk): scaffold apps/agent as a workspace app, a tool that reuses @repo/database, evals, client wiring via eve/react, and deployment as a separate Vercel project. I have this written and dogfooded, and will attach a PR.

Beyond the guide, three deeper (discussion-only, not in the PR) opportunities:

1. First-class apps/agent in the template, gracefully degrading like every other integration (no AI_GATEWAY_API_KEY → agent disabled).
2. Runtime-neutral entrypoints on @repo/* packages — e.g. a conditional export or a /server subpath without the server-only guard, so non-Next server runtimes (agents, workers) can consume them.
3. Node 24 baseline — Eve's floor is Node ≥24; the template currently declares >=18.

Describe alternatives you've considered

• packages/agents as a thin wrapper (like @repo/ai): doesn't fit — Eve agents are deployable apps with their own build/deploy lifecycle, not shared libraries.
• Documenting inside the AI package docs: buries a capability that has its own app-shaped lifecycle.
• Waiting for Eve GA: the guide pins versions and flags beta status instead; the seams above are worth documenting now.