gracefully handle npm rate limits client-side

[43081j]

Its very easy right now to hit npm's rate limit when typing in a search.

When this happens, we mistakenly show the results as 404 rather than pointing out that it has been rate limited.

We really should fix this so a 429 from npm results in a rate limit error and/or a retry after a delay.

[WilcoSp]

maybe an idea to also add debouncing to the search field so that while typing we aren't immediately searching which reduces the chance of being rate limited & reduces bandwidth

[thasmo]

Even some kind of short-term caching would make sense, if not already integrated.

[MatteoGabriele]

Both debounce (250ms) and caching are already in place, as far as I know 👀

[OrbisK]

There is no client side cache atm. This #641 adds client side caching. This should also be the place where we might handle 429 (ofetch has built in retries for certain error codes)

[43081j]

can we handle a 429 as a "back off and retry" instead of a failure?

that would globally solve this even after the changes in 641 i think