fix(web): fail loudly in production when NEXT_PUBLIC_API_URL is unset

[Mamavee001]

closes #155

This already happened once - a real incident, not a hypothetical

While reading the surrounding code I found docs/FIXLOG.md's BUG-1.4 (2026-07-14): a Vercel build once ran with NEXT_PUBLIC_API_URL unset, so apps/web/lib/api.ts's http://localhost:8787 local-dev fallback got baked into the production client bundle, and every visitor's browser silently tried (and failed) to reach localhost:8787 on their own machine - "Create link" just did nothing, no error naming the cause.

That entry's own "Fix" column claims this is "covered by the build-time env check" - but the actual code, right up until this PR, still had the bare, unconditional process.env.NEXT_PUBLIC_API_URL ?? "http://localhost:8787". The fix that actually shipped was a deploy-checklist reminder (MAINTAINER.md), not an enforced guard - so the class of bug was never really closed, just documented. This PR is the enforced version.

What changed

apps/web/lib/api.ts's BROWSER_BASE:

• The localhost:8787 fallback now only applies when NODE_ENV !== "production".
• A production build with NEXT_PUBLIC_API_URL unset throws at module load, specifically in the browser bundle. I used typeof window to distinguish server vs. browser at module-evaluation time rather than inside a function call - this is reliable here (not a runtime toggle) because Next.js produces genuinely separate server and browser bundles, and each evaluates this module's top level for the first time in its own real environment. The server bundle doesn't need NEXT_PUBLIC_API_URL at all if API_URL is set (see apiBase()'s own server branch, unchanged), so it isn't punished for a client-only variable it never actually uses - I deliberately kept this fix scoped to the browser-targeting-its-own-machine failure mode the issue names, not a broader "also crash the server if API_URL is missing" change nobody asked for.
• The thrown error names the variable, states it must be set and rebuilt (not just redeployed - NEXT_PUBLIC_* is baked at build time), and points at the prior incident for context.
• docs/MAINNET.md's existing NEXT_PUBLIC_STELLAR_NETWORK footgun section gained a parallel callout for NEXT_PUBLIC_API_URL with the same "baked at build time, rebuild after changing" framing plus the real incident history - and .env.public.example got the matching inline comment.

Test plan

No Node.js/npm/pnpm runtime is available in the environment this was authored in, and apps/web has no existing unit-test harness to hook a regression test into (only e2e Playwright specs, which exercise a running dev/prod server rather than a production Next.js build's env-var baking specifically - not the right tool for this). I traced through the four branches by hand instead of running anything: variable set (any env); unset + non-production (dev fallback); unset + production + browser (throws); unset + production + server (falls back silently, same as before - server doesn't need this var if API_URL is set).

Please, before merging:

• Run pnpm --filter @checkout/web build with NEXT_PUBLIC_API_URL deliberately unset and NODE_ENV=production and confirm the build/runtime actually throws with the expected message.
• Run pnpm --filter @checkout/api dev / pnpm --filter @checkout/web dev normally (no NEXT_PUBLIC_API_URL set, no NODE_ENV=production) and confirm local development is unaffected, per the issue's own "Done when" criterion.

[drips-wave]

@Mamavee001 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[vercel]

@Mamavee001 is attempting to deploy a commit to the determined's projects Team on Vercel.

A member of the Team first needs to authorize it.