Add sso-diagnose.sh: verify all peertube-sso-incident claims into a log

- docs: record the open identity-forwarding question, auth contracts, and responsibility boundary

docs/peertube-sso-incident.md

@@ -270,6 +270,53 @@ EOF
 > password/LDAP grant for the `xamxam@erg.be` account on PeerTube, **or** register
 > an OIDC client for this app and let us use `authorization_code` + `refresh_token`.
 
+### The open question to put to the admins (the "❓")
+
+Every fact above is **verifiable from the outside** with `sso-diagnose.sh`. The
+one thing it cannot establish remotely is **what authentication information
+LemonLDAP actually forwards to PeerTube after it authenticates a user**. That is
+infrastructure-side configuration, and it is the one remaining unknown.
+
+Three architectures are possible after the migration; the admins must decide
+which one is the *intended* contract for an external app hitting the PeerTube API:
+
+1. **Browser/user SSO** (PeerTube is an OIDC client of LemonLDAP) — the app
+   would use the IdP's `authorization_code` + `refresh_token` (interactive, needs
+   a one-time human login + a registered OIDC client).
+2. **Machine-to-machine** (direct PeerTube API) — needs a non-interactive
+   mechanism (a PeerTube service account / API token), because the IdP does **not**
+   advertise `client_credentials`.
+3. **Reverse-proxy SSO** (LemonLDAP authenticates, forwards identity headers,
+   PeerTube trusts them) — needs LemonLDAP to inject the identity (e.g.
+   `Auth-User`/`X-Remote-User`) **and** PeerTube configured to consume it.
+
+`request-side identity header probe → SKIPPED` in the diagnostic means we have
+**not yet confirmed** that (3) is even wired up — i.e. that PeerTube receives
+*who* LemonLDAP authenticated. That is the next thing to pin down.
+
+Copy-paste ask for the admins:
+
+> `videos.erg.be` is now behind LemonLDAP::NG; its OIDC discovery advertises only
+> `authorization_code` and `refresh_token` (no `password`, no
+> `client_credentials`). Could you confirm what mechanism external applications
+> are now supposed to use to authenticate to the PeerTube API — (1) an OIDC
+> authorization-code flow through `portail.erg.school`, (2) a forwarded
+> authenticated-user identity (and if so, which header), or (3) a separate
+> non-interactive service account / API token? And can you verify that the
+> LemonLDAP-protected `videos.erg.be` vhost forwards the authenticated identity
+> to the PeerTube backend as intended?
+
+### Responsibility boundary (no zero-blame claim)
+
+The *trigger* is unambiguously admin/infrastructure-side: the IdP removed the
+`password` grant the app used, while the credential itself stayed valid (SMTP
+still authenticates). But the app is **not** blameless in design: it coupled
+PeerTube auth to the SMTP password and the `password` grant, so an IdP-side change
+surfaces here. And **if** the app must keep speaking to PeerTube, it *will* need
+code changes — to implement whichever supported grant the admins specify. Those
+changes cannot be written until the admins settle the new authentication contract,
+which is the blocking unknown above.
+
 ---
 
 ## 5. Tooling produced during this investigation
@@ -279,11 +326,17 @@ EOF
 | `scripts/creds-probe.php` | Reads stored creds, probes SMTP AUTH + PeerTube password grant, prints JSON |
 | `scripts/creds-test.sh` | gum UI wrapper; logs results (never the password); `just creds-test` |
 | `scripts/app-token.sh` | gum probe for the long-lived `client_credentials` app-token path; `just app-token` |
+| `scripts/sso-diagnose.sh` | Verifies every claim above (DNS/rDNS, IdP discovery, PeerTube OAuth + password grant, SMTP AUTH, identity-header propagation) into `sso-diagnose.log`; `just sso-diagnose` |
+| `scripts/echo-headers.php` | Request-side echo endpoint to reveal the identity header LemonLDAP injects; pair with `--echo <url>` |
 | `PeerTubeService::probeAuth()` | Public helper isolating token issuance from channel resolution |
 
 All live runs are reproducible:
 
 ```bash
-just creds-test     # proves SMTP ok, PeerTube invalid_grant
-just app-token      # proves client_credentials rejected for the local client
+just creds-test      # proves SMTP ok, PeerTube invalid_grant
+just app-token       # proves client_credentials rejected for the local client
+just sso-diagnose    # full reproducible report → sso-diagnose.log (no secrets)
+# the one remaining unknown (who LemonLDAP forwards to PeerTube) needs
+# scripts/echo-headers.php hosted behind the SAME LemonLDAP vhost:
+#   bash scripts/sso-diagnose.sh --echo 'https://videos.erg.be/path/to/echo-headers.php'
 ```