The single-instance guard belongs at the very top

Desktop. A second launch of your app is a second process. Everything that process does before it discovers it is redundant, it does to files the first process already owns.

The dependency container is where it goes wrong, but not by the mechanism people assume. The container is lazy: a definition is built when something first asks for it, and eagerness is opt-in per definition (single<SettingsStore>(createdAtStart = true)). Constructing the store usually opens nothing either — it builds cold flows, and the file is opened by the first read.

That read is never far away. In the reference it is the statement right after the container starts: a blocking read of the saved language, to pick the UI locale. So the gap between "container up" and "settings file open" is one line — and an eager definition that does touch disk in its constructor closes even that. Either way the guard has to sit above the container.

Two processes then hold the same preferences file, and the store's write path — which saves to a temporary file and renames it over the real one — fails on the operating systems that refuse to replace an open file. Attested on Windows as a rename step failing with an input/output error at launch, before any window appeared.