Fix login lock

docs/auth-model.md

@@ -37,6 +37,18 @@ The first time an operator runs `sherlock copilot` in a fresh environment, the
 agent spawns its MCPs; each MCP triggers its own browser flow as it needs one.
 Subsequent runs are silent until the refresh window opens.
 
+### Concurrent first-use is serialised
+
+Because the loopback port (`127.0.0.1:6990`) is a single machine-wide resource,
+two MCPs hitting their first tool call at the same moment would otherwise both
+try to bind it and one would fail with `EADDRINUSE`. `Ensure` wraps the fresh
+login in an exclusive flock on `$XDG_RUNTIME_DIR/sherlock.login.lock` (sibling of
+the refresh lock, but separate so a long, human-in-the-loop login never blocks a
+quick refresh). The flows queue; after the first one authenticates, the rest
+reuse the operator's existing Authentik browser session and complete without a
+second click. Lock acquisition is context-cancellable, so a waiting flow gives up
+cleanly if its request is cancelled. See `internal/authn/loginlock.go`.
+
 ## Token renewal
 
 Authentik access tokens are short-lived (the `sherlock-cli` provider issues