Keep asking for a banner after one does not fill

[andiwand]

didFailToReceiveAdWithError hid the banner and called onNoAd, and nothing asked again for the life of the controller. The ad unit's automatic refresh only runs for a banner that is on screen — a hidden one is not — so a single refusal left the slot silent until the next document.

It is the same hole droid#643 closes on Android; this is the iOS half.

What changes

• A failure schedules its own ask, rescheduling before each request so one that never comes back cannot end the chain and leave the slot as silent as before. The delay doubles up to the rate the unit refreshes at, so a slot that is never going to fill settles on what the sdk would have done anyway. The first ask is not shorter on purpose: the sdk throttles a burst of failed requests itself, and an ask it answers never reaches the auction.
• A refresh that does not fill keeps the ad already on screen. Any failure used to hide the banner, including one arriving after a good ad had been served — which forfeited the rest of a live impression and, since a hidden banner is not refreshed, stopped the sdk trying again.
• A failed load leaves a CrashManager breadcrumb, as the consent flow already does.

Notes

• Backgrounding needs no guard: a DispatchWorkItem cannot fire while the app is suspended, so unlike the Android side this needs no pause/resume plumbing.
• load()'s width != requestedWidth guard is deliberately bypassed by the retry, which calls bannerView.load directly — a retry wants the same width it just failed at.
• The retry is cancelled on a fill, on the next load(), and in deinit.
• Left alone, and the same on both platforms: a first launch with no network leaves consent undecided and reportNoAd() runs with no retry at all. That deserves its own change.

🤖 Generated with Claude Code