IdP-initiated login flow no longer works - No InResponseTo at the Response, but it was provided the requestId related to the AuthNRequest sent by the SP

Hello,

I have just upgraded GLPI to **11.0.8** and the **samlsso plugin to 1.3.1**. Unfortunately, the IdP-initiated login flow no longer works correctly with WatchGuard AuthPoint.

I have reviewed the configuration and, unfortunately, I have no way of using the magic link described in the documentation:
https://github.com/DonutsNL/samlsso/wiki/Unsollicited-%E2%80%90-IdP-initiated-login-flows

Since our GLPI portal is not publicly accessible, I am willing to accept the compromise of allowing the plugin to accept unsolicited SAML assertions.

However, even after commenting out the following code:

```php
// Only if the registered session is in phase PHASE_SAML_ACS (2) do we allow further
// processing. This check is to prevent parallel requests or intentionally created
// race-conditions forcing the plugin into an inconsistant state possibly allowing
// a session to forcefully being logged in.
/*if ($this->state->getPhase() != LoginState::PHASE_SAML_ACS) {
...
}*/
```

I still receive the following error:

```
No InResponseTo at the Response, but it was provided the requestId related to the AuthNRequest sent by the SP:
ONELOGIN_ae8ff73cd3bd2823cf041cc023b0a2b74c97cadc
```

From what I can tell, the request never even reaches the `PHASE_SAML_ACS` check. This appears to be an issue related to the underlying OneLogin library rather than the phase validation itself.

This issue is quite blocking for us, as almost all of our users authenticate using the **IdP-initiated** flow.

It would be great to have official support for this scenario through a simple configuration option, rather than having to modify the plugin source code manually.

Has anyone else experienced this issue? Is there a recommended workaround, or could this be considered a bug?

Thank you very much for your time and for maintaining this plugin.