Add Spring Authorization Server project: OAuth2/OIDC provider, client and resource server

Three modules on Spring Boot 4.1.1 with Spring Authorization Server 7.1.1: the provider
itself, a relying party, and an API that trusts its tokens. Client registration, PKCE,
a custom consent page and token customisation, with profiles that make each failure
reproducible.

Every claim is backed by captured output in docs/output/as-*.txt, regenerated by
authorization-server/scripts/run-all.sh. Notable findings, verified against the jars:

  - OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(HttpSecurity) was deleted
    in 7.0, and both configuration classes moved into spring-security-config
  - ClientSettings.requireProofKey flipped from false to true, on the authorization server
    (1.5.8 -> 7.1.1) and on the OAuth2 client (6.5.1 -> 7.1.1)
  - requireProofKey(false) does not make PKCE optional for a public client; the code
    verifier is that client's only authentication at the token endpoint
  - MediaTypeRequestMatcher(TEXT_HTML) matches Accept: */*, so the token endpoint answers
    API callers with 302 -> /login unless setIgnoredMediaTypes(ALL) is called

Also renames the repository to spring-auth-demo and cross-links the new chapter set from
the existing documentation.

docs/authorization-server/07-diagnostics.md

@@ -0,0 +1,61 @@
+[← 06 Resource server](06-resource-server.md) · [index](README.md) · next: [08 — The relying party](08-client.md)
+
+# Diagnostics
+
+The interesting configuration in an authorization server is spread across three builders
+and two filter chains, and the effective result is printed nowhere at startup. Reading the
+beans back is faster than reasoning about them.
+
+Source:
+[`ProviderDiagnostics.java`](../../authorization-server/auth-server/src/main/java/com/ankurm/authserver/diag/ProviderDiagnostics.java).
+**Delete it before shipping** — it exposes client ids, scopes, grant types and your
+chain ordering to anyone who can reach `/diag`.
+
+## `/diag/settings`
+
+Every endpoint path the server resolved, including the ones you never configured. Useful
+when a client insists your token endpoint is somewhere else.
+
+## `/diag/clients`
+
+The registered clients as the server actually holds them. This is where
+`requireProofKey: true` on a client you never configured shows up
+([`as-discovery.txt`](../output/as-discovery.txt)):
+
+```json
+{
+  "clientId": "demo-service",
+  "grantTypes": ["client_credentials"],
+  "requireProofKey": true,
+  "requireAuthorizationConsent": false,
+  "accessTokenFormat": "self-contained",
+  "accessTokenTtlSeconds": 600,
+  "reuseRefreshTokens": true
+}
+```
+
+The client secret is deliberately not returned. It is a hash, and printing it invites
+someone to try to use it as a secret.
+
+## `/diag/chains`
+
+The filter chains in the order Spring Security will consult them. If the authorization
+server chain is not first, the token endpoint is unreachable, and this is where you see
+that rather than inferring it from a 302 to `/login`. The equivalent for the resource-server
+project is [`docs/02-filter-chain-and-ordering.md`](../02-filter-chain-and-ordering.md).
+
+## The `trace` profile
+
+```bash
+./scripts/run.sh auth trace
+```
+
+Turns `org.springframework.security` up to TRACE. Verbose, but it is the only way to see
+which `AuthenticationProvider` handled — or declined — a token request.
+
+## Decoding a token without verifying it
+
+`scripts/lib.sh` has `jwt_header` and `jwt_payload`, three lines of base64url each. Debug
+only. Never make a decision on an unverified payload; that is the entire attack.
+
+Next: [08 — The relying party](08-client.md)