Verify upstream Authelia ID tokens

Closes the remaining half of gap G01. The adapter decoded upstream ID-token
claims without verifying anything, justified in a comment by a server-to-server
TLS boundary that nothing enforced.

Operator decision: verify the token rather than police the transport. The hop is
to be HTTPS as defence in depth, but KeyCape does not monitor, check or gate on
that -- a transport check helps only when it is configured correctly, which is
the assumption it was meant to remove. Verification holds regardless of how the
token arrived, so no HTTPS validation or opt-in flag is added.

HandleCallback now verifies the RS256 signature against Authelia's published
keys, the issuer Authelia advertises, KeyCape's own client ID in the audience,
and a sane validity window, before any claim is trusted. It fails closed: an
unreachable or unparseable key set denies the login. The advertised jwks_uri
path is rebased onto the server-side token base URL so split-horizon deployments
resolve, with config overrides where that inference is wrong, and an unknown key
id triggers one refresh so provider rotation needs no restart.

The reusable half lives in internal/jose rather than being copied from
authclient's verifier, since duplicated verification is how two copies drift and
one misses a fix. Migrating authclient onto it is tracked as KEY-WP-0019-T05,
kept separate so it does not destabilise a tested path in this change.

Thirteen rejection cases plus algorithm and rotation coverage; with the
unverified parse restored all fifteen fail, so they test the fix rather than
merely passing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NV9oijZukGyGbRQGGKnK4P

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713576@bnt-lap001
Assistant-Session: 384c511d-9bce-4cb8-a676-2aef6c0c8df6

SCOPE.md

@@ -58,9 +58,11 @@ Keycloak interchangeability are not established.
 - The authorization-code grant now binds the redirect URI,
   enforces grant-type eligibility, authenticates confidential clients and
   consumes codes atomically, and UserInfo enforces algorithm, issuer and
-  access-token purpose (KEY-WP-0016). Upstream provider tokens from Authelia are
-  still accepted on a transport-trust assumption without signature or
-  issuer/audience verification; that gap remains open. Enforcing these bindings
+  access-token purpose (KEY-WP-0016). Upstream Authelia ID tokens are verified
+  before any claim is trusted — signature against the provider's published keys,
+  advertised issuer, own client ID in the audience, validity window — failing
+  closed and independently of transport (KEY-WP-0019). KeyCape deliberately does
+  not check or gate on the upstream transport. Enforcing these bindings
   is not complete profile conformance. Relying parties must repeat `redirect_uri`
   on the token exchange and present the access token, not the ID token, to
   `/userinfo`; see [authorization-code bindings](docs/authorization-code-bindings.md).