Document rate-limit handling and implement Retry-After headers

When GoCardless (or other providers) rate-limits Lunchflow's API calls, we currently return a 503 with the message "Bank data is temporarily unavailable. This usually resolves within a minute."

Without documented retry semantics, client integrations have no spec to work from. Two concrete asks:

1. Document in the API docs how clients should handle 503 responses from Lunchflow when upstream rate limits are hit, including recommended retry windows.
2. Implement a Retry-After header in the response so integrations can handle retries correctly without guessing.

Context: this surfaced because all self-hosted Sure instances default to syncing at 02:22 UTC, creating a thundering herd that hits GoCardless's 100 req/min cap.