fix: skip standalone output on Vercel (missing next-server.js.nft.json)

[ulifehacker]

Summary

• Deploying to Vercel with next@16.3+ fails during packaging: Vercel's build adapter reads .next/next-server.js.nft.json in onBuildComplete, but output: "standalone" builds do not emit that file, so pnpm build crashes with ENOENT ... next-server.js.nft.json. Docker and self-hosted builds are unaffected, which is why the repo unconditionally sets output: "standalone".
• Make the output mode platform-aware: keep standalone for Docker and self-hosted builds, use the standard output on Vercel (detected via the platform-injected VERCEL=1), and allow an explicit override with the new build-time NEXT_OUTPUT_MODE variable.
• Document NEXT_OUTPUT_MODE (and the injected VERCEL) in .env.example and docs/environment-variables.md, and register both in the env governance test.
• Related upstream reports: output: 'standalone' breaks Vercel deployments on Next 16.3 — ENOENT .next/next-server.js.nft.json in onBuildComplete vercel/next.js#96646, 16.3.0: output: 'standalone' + adapter crashes next build — #93684 stops emitting next-server.js.nft.json but copyTracedFiles still requires it vercel/next.js#96657.

Test Plan

• pnpm check:imports
• pnpm format:check
• pnpm hygiene:artifacts - the script itself crashes on Windows (new URL(...).pathname yields C:\C:\...); verified manually that public/ contains no blocked artifacts. Can send a separate one-line fix if useful.
• pnpm lint
• pnpm typecheck
• pnpm test - 397/399 files pass; the 3 workerSize.test.ts cases fail on Windows with spawn EINVAL (Node 24 refuses .cmd shims), unrelated to this change.
• pnpm test:e2e
• pnpm build - verified locally on Windows with the OpenNext dev init temporarily stubbed (workerd cannot start natively on Windows); .next/standalone/ is still emitted when VERCEL is unset, so the Docker path is unchanged.
• pnpm build:worker
• pnpm worker:size
• pnpm worker:dry-run
• pnpm audit --prod --audit-level moderate

Notes

• I updated docs or examples when behavior changed.
• I considered local-first data handling and hosted deployment safety.
• I added or updated tests for user-facing or security-sensitive changes (env governance registry; the change itself is build-time configuration covered by pnpm build).
• For localization changes, I followed docs/localization-pr-guide.md and documented intentional English fallbacks. (no localization changes)

[Amery2010]

While the issue can be bypassed using the standard VERCEL=1 environment, upgrading to Next.js 16.3.5 is a more complete and superior solution.

Thank you for the new feedback, I have already fixed this in the latest version, v2.5.2.