fix(login): treat already-logged-out as success in backchannel logout (#1430)

[SAY-5]

Closes #1430.

Summary

Per OIDC Backchannel Logout 1.0 §2.6:

If the identified End-User is already logged out at the RP when the logout request is received, the logout is considered to have succeeded.

Today backChannelLogout() returns HTTP/400 when the (sid, iss) or (sub, iss) lookup yields no matching session, which is exactly the already-logged-out case the spec calls out as a success. The reporter (running LemonLDAP) sees a confusing error surfaced on the IdP UI even though the desired state — the RP session being gone — is already true. The same shape would happen with Keycloak, Authelia, etc.

Change

Only the two "session not found" paths flip to HTTP/200:

• findSessionBySid → DoesNotExistException ⇒ return HTTP/200 OK + debug log.
• findSessionsBySubAndIss returns empty ⇒ return HTTP/200 OK + debug log.

The other validation branches in the same method — invalid issuer, invalid signature, malformed token, missing claims, multiple-sessions-found — keep their HTTP/400 responses. Operators that need visibility into already-logged-out backchannel calls can flip Nextcloud's loglevel to debug and see the [BackchannelLogout] line.

Mirrors the proposed fix in the issue and the spec citation.

Test plan

• No LoginControllerTest exists in tests/unit/Controller/ today, and the existing integration runner under tests/integration/ does not cover the backchannel flow. The change is two short branches that swap a getBackchannelLogoutErrorResponse() for new JSONResponse([], Http::STATUS_OK) plus a debug log; both branches are syntactically equivalent to the existing return new JSONResponse([], Http::STATUS_OK) at the end of the success path.
• Ran git diff --check clean.
• Verified the spec citation against the linked RFC section.

Notes

• This is the spec-compliant behavior; existing IdPs will start receiving cleaner success responses for the already-logged-out case.
• The optional "debug checkbox" the reporter floated is left for follow-up — the spec is unambiguous, so a per-provider opt-out adds configuration surface for no clear benefit.

[Spitfireap]

Thanks !
tested on v33.0.2 without any issue. It's working as intended