fix: track Ponder fallback routing as a flag, not a URL comparison

[Danswar]

Summary

Ports d-EURO#123 (same api.apollo.config.ts, forked codebase).

• errorLink decided whether a failed Ponder request already went to the fallback by comparing operation.getContext().targetUrl against CONFIG.indexerFallback as strings.
• DFXServer/server#869 sets CONFIG_INDEXER_FALLBACK_URL to the same host as CONFIG_INDEXER_URL on both dfxprd and dfxdev (the only way to keep the var populated without leaking prd traffic onto dev). With primary and fallback string-identical, the comparison is true on every request regardless of which URL it actually went to, so the warn + retry branch could never execute — every network error would still fall through to logger.error, making #869 alone insufficient to fix the noisy error-level logging observed in Grafana for juicedollar-jdm-api.
• Fix: routingLink now stamps usedFallback: isFallbackActive() at send time, and errorLink reads that flag instead of re-deriving it from a URL comparison.

Test plan

• Verified same logic already confirmed correct upstream in fix: track Ponder fallback routing as a flag, not a URL comparison d-EURO/api#123 (traced retry path: routingLink re-stamps context on retry from the now-fallback-active state, so a second failure against the fallback still correctly falls through to error).
• After merge + redeploy alongside DFXServer/server#869: watch Loki for juicedollar-jdm-api ApiApolloConfig network-error lines to move from error to warn on the next transient Ponder blip.

[Danswar]

Superseded by #63 — rebuilt on a fresh branch to fix the PR body/commit message referencing internal infra details that shouldn't be in a public repo. Same fix, same file.