ci: raise the coverage gate to 90 percent; docs: reconcile OAuth docs with the implementation

docs/deployment.md

@@ -9,8 +9,12 @@ hands the power of its Gitea token to every client that can authenticate.
 - Admin-token only: set `GITEA_TOKEN` and `MCP_BEARER_TOKEN`. Every client with the bearer token
   acts as the token owner.
 - Per-user OAuth: additionally set `OAUTH_ENABLED=true` with the OAuth settings. Users sign in
-  with their own Gitea account and act under their own permissions. The static bearer keeps
-  working next to it as the admin identity; leave `MCP_BEARER_TOKEN` unset to turn that off.
+  with their own Gitea account (after a consent step on `/oauth/consent`) and act under their
+  own permissions. The static bearer keeps working next to it as the admin identity; leave
+  `MCP_BEARER_TOKEN` unset to turn that off.
+- OAuth only: `OAUTH_ENABLED=true` with neither `MCP_BEARER_TOKEN` nor `GITEA_TOKEN`. The server
+  starts and serves signed-in users only; admin-token mode does not exist in this deployment, so
+  no request can ever fall back to an admin identity. Recommended for public deployments.
 
 ## Docker
 
@@ -50,7 +54,7 @@ Points that matter:
 - The port is published on `127.0.0.1` only. The reverse proxy on the same host is the public
   entry point.
 - `DATA_DIR` must be a persistent volume writable by the container user. It holds the audit log
-  and the encrypted OAuth token store (`oauth-tokens.json`, mode 0600). Losing the volume loses
+  and the encrypted OAuth token store (`oauth-store.json`, mode 0600). Losing the volume loses
   all OAuth logins and the audit history. Back it up, and protect the backup like the secrets it
   protects.
 - Keep `.env` out of version control and out of the image (mode 0600; `setup` writes it that
@@ -104,6 +108,12 @@ Gitea has no instance-wide OAuth application API, so the application belongs to
 that created it. Re-running setup reuses it; if the stored client secret is missing, Gitea has to
 regenerate it, and setup asks before doing so.
 
+Before the browser is sent to Gitea, the consent page `/oauth/consent` shows the client name and
+the redirect URI, because Gitea remembers consent for this one application and any client can
+register itself. For a public deployment also set `OAUTH_REDIRECT_ALLOWLIST` to the hosted
+clients you use, for example `https://claude.ai/,https://chat.mistral.ai/` (see
+[configuration.md](configuration.md)).
+
 `OAUTH_SCOPES` is the scope list sent to Gitea. Keep it to granular scopes. Narrow it (for
 example to `read:repository,read:issue`) to limit what signed-in users' tokens can do through this
 server regardless of their Gitea rights.
@@ -111,8 +121,9 @@ server regardless of their Gitea rights.
 ## Upgrades
 
 - Application: pull the new image (or package) and restart. The data volume is kept.
-- `TOKEN_ENCRYPTION_KEY` must stay the same, or stored OAuth logins can no longer be decrypted
-  and users have to sign in again.
+- `TOKEN_ENCRYPTION_KEY` must stay the same. A store written with another key stops the server
+  at startup (exit code 2, the file is kept) instead of being wiped: restore the old key, or move
+  `DATA_DIR/oauth-store.json` away to start over, which signs every OAuth user out.
 - Upgrading Gitea: tool names and schemas come from the pinned swagger, so a Gitea upgrade does
   not change them. To pick up a newer API, re-pin the swagger and regenerate the catalog: