Fix PWA 401: read auth env at runtime, not build time

[ralyodio]

The deployed PWA returned 500 on every dynamic page. The underlying cause was a 401 from the API — while the exact same credentials returned 200 by curl, and the tokens on both services hashed identically.

Cause

Next.js statically replaces process.env.SOME_NAME during the build. The web image was built before the credentials were set, so this:

...(process.env.API_TOKEN ? { authorization: `Bearer ${process.env.API_TOKEN}` } : {}),

was baked in as undefined, the ternary collapsed to false, and the request went out with no auth headers at all — permanently, regardless of what the container environment said later. Setting the variables and redeploying could never have fixed it; only a rebuild would, and that would bake a secret into the image.

Reading through an accessor that indexes process.env with a non-literal key defeats the substitution, so the value is genuinely read from the running container:

function runtimeEnv(name: string): string | undefined {
  const key = String(name);
  return process.env[key];
}

NEXT_PUBLIC_* stays a direct reference, since inlining is the intent there.

Also: a 401 should not be a 500

The auth failure escaped as an unhandled error and Next rendered a generic 500, which tells an operator nothing. ApiAuthError is now distinct from ApiUnavailableError — one means bad credentials, the other means the service is down, and they have different fixes. Each screen renders the relevant explanation and names the variables to check.

Verification

Typecheck clean, next build clean, 265 tests pass.

🤖 Generated with Claude Code