v4: an instance can be named by the address of its pages — sign-in and the trust list took only an instance's issuer, its API's origin, so where the pages live elsewhere the address people see in their browser named no instance: in development, localhost:3000 answered its /.well-known with index.html, and the sign-in failed as "doesn't answer as a gerbeur". resolveIssuer (remote/gerbeur-instance.ts) now reads the metadata at the address given and, when it names another issuer, takes it only if that issuer's own metadata names those pages back as where its /authorize is, so an impostor can't claim one; sign-in, the trust list and the check against this instance go through it. The Vite dev server passes /.well-known on to its API, as whatever serves the pages must in production (README). A handle still carries the API's host.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

API.md

@@ -218,7 +218,11 @@ account on another gerbeur instance, their home, by OpenID Connect's
 authorization code flow with PKCE, with tokens signed by each instance's Ed25519
 key. With `GERBEUR_FEDERATION_INCOMING=0`, `POST /api/federation/logins` and
 `/sessions` answer 403; with `GERBEUR_FEDERATION_OUTGOING=0`,
-`GET /api/oauth/clients` and `POST /api/oauth/codes` do.
+`GET /api/oauth/clients` and `POST /api/oauth/codes` do. An instance is named by
+its issuer, its API's origin, whose host is the one in its users' handles. Where
+`instance` is asked for, the origin of its pages works too: their
+`/.well-known/openid-configuration` names the issuer, whose own metadata must
+name those pages back as where its `/authorize` is.
 
 - `GET /.well-known/openid-configuration`, `/.well-known/jwks.json` — anyone.
   The instance's metadata and public keys, bare JSON: the one exception to the