fix(sso): stop a SAML LogoutResponse from ending a session it never belonged to

[marevol]

What

/sso/logout accepted an unsigned, unsolicited SAML LogoutResponse and ended
whatever session the request carried. This keeps the session for that kind of
message, and reports one bounded line when the message reached a login that was
still live.

Why

/sso/logout is anonymous, and because SAML requires SameSite=none on the
session cookie it is reachable cross-site with the victim's cookie attached.

Auth#processSLO was given null as the request ID, so java-saml skipped the
InResponseTo comparison. With the shipped saml.security.want_messages_signed=false
every remaining check is conditional on an attribute the sender may simply omit:
Issuer, Destination, and the InResponseTo attribute itself. A
LogoutResponse containing nothing but a Success status therefore passed
validation, and processSLO invalidated the session.

The SP has no request ID to give: LogoutAction asks the SSO manager for the
redirect URL and then calls logout(), which invalidates the session that would
have held it. So the binding cannot be restored by storing the ID there.

Measured on a Keycloak-backed setup, against master:

	before	after
live SAML login, forged LogoutResponse	session ended, 0 log lines	session kept, 1 WARN
local (non-SAML) login	session ended	session kept
login still in flight	session ended, and the pending AuthnRequest ID with it, so the login could not complete	login completes
SP-initiated SLO round trip	login ended	login ended, no WARN
LogoutRequest naming the session's own user	session ended	session ended
LogoutRequest naming another user	session kept (#3262)	session kept

The impact is denial of service rather than escalation: an attacker ends
sessions and, while the request keeps being made, prevents logins from
completing. saml.security.want_messages_signed=true already prevented it,
which is why the start-up banner recommends it — but the shipped default did not.

How

• A LogoutResponse no longer ends the local session. Nothing is lost by that:
  a legitimate one answers a LogoutRequest this SP sent, and by the time it can
  arrive LogoutAction has already ended the login, so the session it lands on
  is a fresh one. This is the same exposure the NameID comparison closes for a
  LogoutRequest (fix(sso): refuse a SAML LogoutRequest that names another user #3262); a LogoutResponse carries no NameID, and needs none,
  because there is nothing left for it to end.
• A LogoutResponse that reaches a session which is still logged in is reported.
  That never happens on the path a logout actually takes, so the legitimate round
  trip stays silent. The line is bounded, carries no stack trace and echoes
  nothing the sender supplied — an anonymous endpoint must not let an
  unauthenticated client fill the log.
• A request carrying both parameters stays on the LogoutRequest branch, decided
  the same way round as Auth#processSLO reads them.

Tests

SamlAuthenticatorTest 75 tests green (3 added), and 235 green across the
related SSO/exception suites.

Verified end to end against a Keycloak IdP: the forged message is refused and
reported, a login in flight completes afterwards, the SP-initiated SLO round trip
still ends the login without a warning, and both LogoutRequest cases behave as
before. Reverting the change turns six of those assertions red, so they are not
vacuous.