AUTH4D-225 session.revoked on refresh-token revocation

AUTH4D-225 fixes BUG-AUTH4D-198-3: revoking a refresh token at POST /oauth/revoke ended the session but published no session.revoked event (AUTH4D-158), so webhooks and Flows never heard of it. No contract, route or migration changes.

Behaviour

Every OAuth path that ends a session now goes through the session service’s logout, which reports whether that call ended the session. Only that call publishes session.revoked and runs the post_sign_out trigger, so each session is reported once whatever the order of revocations.

Revoking the refresh token and then the access token (or the other way round), revoking either after sign-out or an administrator’s revocation, or revoking the same token twice publishes nothing more. Revoking a refresh token now ends every refresh family of its session, which the session’s revocation already implied. A refresh token presented by another client still ends nothing and publishes nothing. /oauth/revoke keeps answering 200 {} in every case (RFC 7009).

The silent revocation when a browser application that opted out of refresh presents a refresh token at /oauth/token (AUTH4D-63) still publishes nothing.

Tests

tests/integration/auth4d-225.session-revoked.test.ts, through the real API composition, counts the session.revoked events and post_sign_out triggers for refresh-token revocation (once, again, another client), both tokens in each order, sign-out followed by access-token revocation, and an administrator’s revocation followed by both tokens. It also fans the published events out to a webhook endpoint subscribed to session.revoked and checks exactly one delivery. The four refresh-token tests fail without the fix.