fix: stop re-requesting bot avatars that GitHub has no record of

[austenstone]

Found by reading the browser console while verifying #110 renders, not by any test or check.

Loading the sample data fires two identical requests for the same user ~200ms apart:

[ERROR] 404  https://api.github.com/users/lisa-huang%5Bbot%5D
[ERROR] 404  https://api.github.com/users/david-liu%5Bbot%5D
[ERROR] 404  https://api.github.com/users/david-liu%5Bbot%5D    <- again
[ERROR] 404  https://api.github.com/users/lisa-huang%5Bbot%5D   <- again

Why

resolveBotAvatar caches on success only:

if (url) {
  botAvatarCache.set(username, url);
  persistAvatarCache();
}

A 404 leaves the cache untouched. The in-flight pendingFetches map does collapse concurrent calls, but it's cleared in .finally(), so it does nothing for the next pass. preloadBotAvatars then filters on !botAvatarCache.has(u) and re-selects the exact same unresolvable bots every time it runs.

There was already a test for concurrent dedup, which is why this survived — it covered the case that worked and not the one that didn't.

Why it matters

These requests are unauthenticated: 60 per hour per IP. A real report with bots that no longer resolve (deleted app, renamed org, GHES users who don't exist on github.com) spends that budget on repeats and then every avatar fails, including the ones that would have resolved fine.

Fix

Track unresolved usernames in a module-level Set and check it in resolveBotAvatar and the preloadBotAvatars filter.

Deliberately not persisted. A localStorage entry would be permanent, so a bot created or renamed later could never resolve. In-memory means it stops the hammering within a session and a reload retries.

Verification

Four new tests. Confirmed load-bearing — reverting the guard fails exactly the two that should fail:

× does not re-request a bot the API had no avatar for
× does not re-request a bot whose lookup threw
Tests  2 failed | 15 passed (17)

Full suite 290 passed, lint and typecheck clean, build succeeds.

Note

Stacked on #110 → #109. The console also shows five Highcharts warning #33 entries about invalid config attributes; those are pre-existing and unrelated, not touched here.