Retry/backoff + friendly error mapping for simulation entrypoint 429s; cache the versions map

During the 2026-09-01 simulation-entrypoint outage (PolicyEngine/policyengine-sim-api#674), the v1 API turned an upstream 429 Too Many Requests into a raw 500 shown verbatim in app-v2:

Society-wide calculation failed (500): {"status": "error", "message": "Client error '429 Too Many Requests' for url 'https://simulation.api.policyengine.org/versions/policyengine'\nFor more information check: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429", "result": null}

Two hardenings in policyengine_api/libs/simulation_entrypoint.py (and the economy service around it):

1. Bounded retry with backoff on 429/503 for the cheap control-plane calls — resolve_app_name (GET /versions/policyengine, GET /versions/{country}) and job polling. These are tiny idempotent GETs; a 3-attempt exponential backoff (~0.5s/2s/8s, honoring Retry-After when present) would have ridden out the burst edges instead of failing user reports instantly. Do NOT retry job submission unconditionally (double-spawn risk).
2. Error mapping: upstream 429/5xx should surface as a retryable "computing infrastructure is busy, try again shortly" status/message to clients, not an httpx exception string with an MDN link. The raw string ends up rendered in the app's report error card.

A versions-map cache (short TTL, e.g. 60s) in the v1 API would also remove the /versions/policyengine round-trip from the critical path of every economy calculation — it changes only on sim-api deploys.

Start in policyengine_api/libs/simulation_entrypoint.py, tracing resolve_app_name and job polling, then inspect the surrounding economy service. Confirm how control-plane GET failures and submission errors reach clients before defining the retry and mapping boundaries. Done means bounded 429/503 retries with Retry-After support, friendly retryable errors, and a short-TTL versions-map cache without unconditional job-submission retries.