SearXNG support

docs/auth-model.md

@@ -5,7 +5,7 @@ master session: each MCP authenticates for the service it calls.
 
 ## Lifecycle
 
-For a service such as `gitea`, `grafana`, or `gssh`, the MCP asks
+For a service such as `gitea`, `grafana`, `gssh`, or `searxng`, the MCP asks
 `internal/authn` for a token on first use:
 
 1. Fresh wallet entry: return it.
@@ -15,17 +15,18 @@ For a service such as `gitea`, `grafana`, or `gssh`, the MCP asks
    serialized by `$XDG_RUNTIME_DIR/sherlock.login.lock`, persist, return.
 
 Long-running MCPs use `TokenSource` and `TokenHolder` so requests always read
-the latest bearer. Refresh never opens a browser; if refresh can no longer
-recover, the next invocation performs a fresh login.
+the latest bearer. Refresh follows access-token expiry, never opens a browser,
+and falls back to a fresh login on the next invocation if refresh can no longer
+recover.
 
 ## Service identity
 
 The config supplies issuer, client ID/secret, and base URL. Scopes are owned by
 each MCP because they follow the tool surface, not the deployment.
 
-Gitea uses Gitea's OAuth2 server. Grafana and Gssh normally reuse the shared
-Authentik `sherlock-cli` provider. Tokens are stored and refreshed per service
-and are not reused across unrelated services.
+Gitea uses Gitea's OAuth2 server. Grafana, Gssh, and SearXNG normally reuse the
+shared Authentik `sherlock-cli` provider. Tokens are stored and refreshed per
+service and are not reused across unrelated services.
 
 ## User controls