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

[Danswar]

Summary

Ports d-EURO#124 (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.
• This repo's own deploy config sets CONFIG_INDEXER_FALLBACK_URL to the same host as CONFIG_INDEXER_URL in both environments (the way to keep the var populated without leaking traffic across environments). 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 the deploy-config change alone insufficient to fix the noisy error-level logging observed for this service.
• 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

• Traced the retry lifecycle: 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. Confirmed this repo's own api.config.ts sources the same env vars as d-EURO/api, so the fix is not inert here.
• After merge and the accompanying deploy-config update: watch for network-error log lines to move from error to warn on the next transient Ponder blip.

(Supersedes #62, closed — that PR's description/commit message referenced internal infra details that don't belong in a public repo.)

[Danswar]

3 review passes to 0 findings. This ports an already-verified fix (d-EURO#124) unchanged, so logic passed clean on the first pass. Two follow-up passes on wording caught and fixed public-repo hygiene issues in the PR description, commit message, and a code comment — internal terminology replaced with generic phrasing. Final state: no outstanding issues, CI green.