fix: reclassify Apollo network-error log severity

[TaprootFreak]

Summary

Reclassify recoverable Apollo network errors from error to warn so the
transparent indexer-fallback retry path no longer inflates the dfxprd
error-rate panels. Also tighten the fallback window and drop log payload
fields that the active log formatter silently discards.

Tracked in DFXServer/server#278;
parallel PR for the sister codebase at
JuiceDollar/api#58.

Investigation

Sampled 2026-06-01 ~11:00 CEST on dfxprd (Loki):

Container	error/60m	error/24h
deuro-deuro-api-8	47	977

Every error [ApiApolloConfig]: [Network error in operation: …] line on
dfxprd is paired 1:1 with an info [ApiApolloConfig]: [Ponder] Network error detected, activating fallback line — i.e. every error is the
recoverable transient-hiccup path, not a real outage. The system handles
them via forward(operation), the user-facing request retries, but the
log entry already shipped at error severity.

GraphQL-errors path: 0/24h on dfxprd — confirms the noise is purely
from the network-error path.

Two latent problems found while tracing this:

1. Metadata payload was silently dropped. The Winston formatter in
   api.main.ts is format.printf((info) => \${info.level} [${info.context}]: ${info.message}`)— it only readsinfo.message. The { message, name, stack }second argument tologger.error(...)was never reaching Loki. InliningnetworkError.message` into the main string keeps the signal that
   was being silently lost.
2. activateFallback() only armed once per process lifetime. Guard
   was if (!fallbackUntil), which stays falsy only until the first
   activation. After the 10-min window expires, the guard fails and
   fallbackUntil is never refreshed, so the "Switching to fallback"
   log fires exactly once per container boot (confirmed via Loki: 0
   matches in 24h despite ongoing activity).

Change

 if (networkError) {
-    logger.error(`[Network error in operation: ${op}]`, { message, name, stack });
-
-    if (getIndexerUrl() === CONFIG.indexer) {
-        const is503 = ...;
-        if (is503) logger.log('[Ponder] 503 Service Unavailable - …');
-        else       logger.log('[Ponder] Network error detected, …');
-        activateFallback();
-        return forward(operation);
-    }
+    const hasFallback = !!CONFIG.indexerFallback;
+    const onFallback = getIndexerUrl() !== CONFIG.indexer;
+    const willRecover = hasFallback && !onFallback;
+    const msg = `[Network error in operation: ${op}] ${networkError.message}`;
+
+    if (willRecover) {
+        logger.warn(msg);
+        activateFallback();
+        return forward(operation);
+    }
+    logger.error(msg);
 }

Plus activateFallback() re-arm:

-if (!fallbackUntil) {
+if ((!fallbackUntil || Date.now() >= fallbackUntil) && CONFIG.indexerFallback) {

The GraphQL error branch loses its { locations, path } payload for the
same reason (Winston discarded it) — error.message is appended to the
main string instead.

Behaviour matrix

Scenario	severity	retries?
Primary fails, fallback configured & different URL, first time	warn	yes, via fallback
Primary fails, fallback configured & different URL, already on fallback	error	no (propagate)
Primary fails, CONFIG_INDEXER_FALLBACK_URL == CONFIG_INDEXER_URL (current PRD)	warn	yes, same URL
Primary fails, no fallback URL configured	error	no
GraphQL error	error	no (unchanged)

Expected post-deploy effect on dfxprd

With the current CONFIG_INDEXER_URL == CONFIG_INDEXER_FALLBACK_URL
config (intentional, see compose comment about the prior PRD→DEV
traffic leak), willRecover evaluates to true for every network
error. So:

• ApiApolloConfig error-level lines from network errors: ~977/d → 0/d
• ApiApolloConfig warn-level lines from network errors: 0/d → ~977/d
• Residual error-level entries: graphQL-errors path only (0/24h baseline)

A real outage where the retry also fails still surfaces at error level
if a distinct fallback URL is configured. For PRD today (same-URL
fallback), real outages will show as elevated warn-rate; switching
fallback to a distinct indexer is a separate infra decision.

Verification query:

sum(count_over_time(
  {server="dfxprd", container_name="deuro-deuro-api-8"}
  | detected_level="error" |= "ApiApolloConfig" [60m]
))

Test plan

• yarn build clean (verified locally on the branch HEAD)
• yarn lint clean (verified locally on the branch HEAD)
• npx prettier --check api.apollo.config.ts clean
• After deploy to dfxprd: Loki error-rate for deuro-deuro-api-8
ApiApolloConfig drops to ~0; warn-rate picks up the same volume.
• Verify [Ponder] Switching to fallback for 10min: … log emits
  on first activation per window (and re-emits after window expiry).