feat(config): refuse to start a misconfigured container

Three misconfigurations in a row were each diagnosed the same slow way: deploy,
try to sign in, read a status code, guess, read a response body, guess again.
That is a property of the design, not of bad luck. Every required variable is
read lazily, on the first request that needs it, so a container missing its
environment starts clean, serves the sign-in page, and passes a healthcheck
while being completely unable to authenticate anybody.

The lazy reads have to stay — reading at module scope fails `next build`, which
collects page data with NODE_ENV=production and none of these variables set
(that is the "Failed to collect page data for /api/assistant" failure already
documented in apiClient). So the check goes in an instrumentation hook instead,
which Next runs once per server start and NEVER during a build: it returns early
when NEXT_PHASE is 'phase-production-build', in
server/lib/router-utils/instrumentation-globals.external.js.

Boot now either prints what it resolved:

  [loyaly] config ok — platform https://mcp.loyaly.ai, auth secret set, NODE_ENV=production

or refuses to start, naming every problem at once rather than one per deploy:

  refusing to start — 2 configuration problem(s):
    1. LOYALY_API_BASE is invalid: https://api.example.com is not a supported production API host...
    2. AUTH_SECRET is required in production — it signs the session cookie...

Verified against a real standalone build, booted four ways: unconfigured, fully
configured, LOYALY_API_BASE pointed at the console, and both wrong at once.

The platform origin and its validation move to shared/config/platformApi. This
is load-bearing, not tidying: apiClient is `server-only`, and that package
resolves to a module which THROWS ON IMPORT outside a react-server condition —
which the instrumentation bundle is not. Importing apiClient from the boot check
would have crashed every start, correctly configured or not. The extracted
module imports nothing but ConfigError, so the boot check and the request path
run the same function against the same allowlist.

Also corrects a claim I made in the Dockerfile two commits ago. `next build`
DOES copy .env into .next/standalone — writeStandaloneDirectory takes exactly
.env and .env.production and nothing else — so the explicit COPY is redundant
rather than required. It stays, with an accurate reason: it only happens when
.env is in the build context, and .dockerignore excluded it until recently.
Keeping the COPY makes that dependency fail the Docker build loudly instead of
producing an unconfigured image.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Dockerfile

@@ -71,16 +71,19 @@ COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
 
 # The production environment, as a file the server reads at boot.
 #
-# `next build` does NOT fold .env into .next/standalone — the standalone output
-# carries server.js and traced node_modules, nothing else — so without this line
-# the running container has no LOYALY_API_BASE and every upstream call throws
-# "required in production". server.js chdirs to /app and Next calls
-# loadEnvConfig on it, which is why the file belongs beside server.js at the
-# WORKDIR root and not under .next/.
+# Deliberately redundant, and worth keeping. `next build` already copies .env
+# (and .env.production, and nothing else — see writeStandaloneDirectory in
+# next/dist/build/index.js) into .next/standalone, so the line above lands one
+# at /app/.env on its own. But it only does that when .env was in the BUILD
+# CONTEXT, and .dockerignore excluded it until recently — which is precisely
+# how images shipped with no LOYALY_API_BASE at all.
 #
-# This does not pin the deployment: @next/env never overwrites a variable that
-# is already in process.env, so anything set in Dokploy still wins over this
-# file. It only removes "unset" from the set of possible states.
+# This line turns that silent outcome into a loud one: exclude .env again and
+# the Docker build FAILS here with "file not found" instead of producing an
+# unconfigured image that starts and then rejects every sign-in.
+#
+# It does not pin the deployment either way: @next/env never overwrites a
+# variable already present in process.env, so anything set in Dokploy wins.
 COPY --chown=nextjs:nodejs .env ./.env
 
 USER nextjs