config: fix silently dropped triggered config refetch when already in-flight

[garmr-ulfr]

Summary

A UserChangeEvent firing while a poll-driven fetch was in flight could race the atomic dedup guard, be silently skipped, and leave the handler on stale config until the next ~10-minute poll tick — so after a login, the user could remain on pre-login config for up to ten minutes.

Replaces the atomic.Bool dedup with a mutex-protected fetching/pending pair. A caller arriving during an in-flight fetch sets pending and returns immediately; the in-flight loop re-runs doFetchConfig once after the current one returns, picking up the freshest identity for the second request. Worst case after an event storm: one extra HTTP round-trip on the stale-identity fetch, then a fresh one.

[Copilot]

Pull request overview

This PR fixes a race where a UserChangeEvent-triggered config refresh could be skipped while a poll-driven fetch was already in-flight, leaving the app on stale config until the next poll tick.

Changes:

• Replace the atomic “in-flight” guard with a mutex-protected fetching/pending mechanism that coalesces concurrent fetchConfig calls into (at most) a follow-up fetch after the current one completes.
• Refactor the existing fetch logic into doFetchConfig() to support the coalescing loop cleanly.
• Add a concurrency regression test and make LocalBackend.Start() call confHandler.Start() synchronously.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
config/config.go	Adds mutex-guarded coalescing to prevent missed refreshes during in-flight fetches; factors fetch body into doFetchConfig().
config/config_test.go	Adds a blocking fetcher + test to verify concurrent calls schedule exactly one coalesced follow-up fetch.
backend/radiance.go	Ensures confHandler.Start() runs deterministically during backend startup (no goroutine wrapper).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[myleshorton]

Nice! I think this also means that callbacks associated with that config won't happen right? Which will mess up the bandit.

[garmr-ulfr]

I think this also means that callbacks associated with that config won't happen right? Which will mess up the bandit.

That's a good question. Are you referring to the offline URLTests?