Ask for the picture the way providers actually offer it

Two assumptions, both mine, and either one was enough for an account to end
up with no picture. It was looked for only in the ID token, which a provider
is free to keep lean while holding the rest at userinfo — PocketID does
exactly that — and the endpoint was never asked. Then the image was fetched
with no credentials, while avatars are commonly behind the provider's own
login.

Userinfo is now asked when something is missing, and believed only when its
sub matches the token whose signature was checked. The access token rides
along with the picture request when, and only when, the picture lives at the
provider.

The third fault was the one that cost the time: it failed silently, so there
was no way to tell which of the two it was. Every outcome is a line in the
log now. And the test provider keeps its picture out of the token and behind
its door, so the check passing is evidence for both new paths.

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

e2e/oidc.mjs

@@ -130,6 +130,9 @@ try {
     src: img.currentSrc || img.src,
     width: img.naturalWidth,
   }));
+  /* The provider keeps this one out of the token and behind its own door, which
+     is what a lean provider does — so this passing means both the second
+     question to /userinfo and the token sent with the picture request. */
   check(drawn.width > 0, "the profile picture from the provider is drawn", JSON.stringify(drawn));
   check(
     drawn.src.startsWith("blob:"),