Document the authorization-code bindings for relying parties

KEY-WP-0016 changed /token and /userinfo behaviour with no consumer-facing note;
nothing in docs/ mentioned redirect_uri, so the change would have reached a
deployment silently.

States what an exchange must now send, who is affected and how to roll out.
Every browser registration in dev-config is public with an authorization_code
grant, so only the redirect_uri requirement can affect them; the realistic
failure is a client that sends it to /authorize and omits it at /token, which
has not been observed against a live consumer.

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

@@ -50,7 +50,10 @@ Keycloak interchangeability are not established.
   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
-  is not complete profile conformance. See the assessment below.
+  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).
+  See the assessment below.
 - Tests cover local handlers, adapters, transformations and CLI protocol behavior.
   They do not establish complete replacement against a running Keycloak/full-LDAP
   stack. The Scenario B/C shell harnesses are incomplete.