fix: Wire up Device Storage Method session setting to SDK configuration

[Flowgram]

Summary

The Device Storage Method setting in the plugin UI (Advanced > Sessions) allows administrators to choose between "Encrypted Cookies" and "PHP Native Sessions (Recommended)". However, importConfiguration() in Plugin.php never reads this option - the SDK always defaults to CookieStore regardless of the selected setting.

This PR fixes two related bugs:

• Plugin.php: Read the sessions.method option and configure a SessionStore on the SdkConfiguration when "PHP Native Sessions" is selected
• Authentication.php: Guard the setState() call in onShutdown() with an instanceof CookieStore check, since setState() is CookieStore-specific and causes a fatal error (Call to undefined method Auth0\SDK\Store\SessionStore::setState()) when SessionStore is in use

Context

When the plugin uses CookieStore (the effective default regardless of UI setting), the entire user session - ID token, access token, refresh token, and user profile - is serialized and encrypted into cookies. These get chunked across multiple cookies (auth0_session_0, auth0_session_1, auth0_session_2, etc.) which, combined with standard WordPress auth cookies, can exceed nginx/server default header buffer limits (typically 8KB), resulting in:

400 Bad Request
Request Header Or Cookie Too Large

Switching to PHP Native Sessions (as the UI already advertises) stores session data server-side and only sends a small session ID cookie, completely avoiding this issue.

Changes

src/Plugin.php

• Added use Auth0\SDK\Store\SessionStore import
• After creating the SdkConfiguration, check if sessions.method is 'sessions' and call setSessionStorage() with a new SessionStore instance

src/Actions/Authentication.php

• Replaced the @var CookieStore type annotation + unchecked setState() call with a proper instanceof CookieStore guard

Test plan

• With Device Storage Method set to "Encrypted Cookies": verify login works as before (cookies are set)
• With Device Storage Method set to "PHP Native Sessions (Recommended)": verify login works and no auth0_session_* cookies are set
• With Rolling Sessions enabled and PHP Native Sessions selected: verify no fatal error on setState()
• With Rolling Sessions enabled and Encrypted Cookies selected: verify setState() still functions correctly

[kishore7snehil]

SessionStore also doesn't call session_write_close() anywhere, and WordPress doesn't either. PHP sessions lock the session file for the entire request, so concurrent AJAX requests from the same user will queue up and wait for each other instead of running in parallel. Might cause noticeable slowness in the admin.

[Flowgram]

That's exactly what happens. Visiting an AJAX-heavy page in the admin causes my local environment to crash with ERR_CONNECTION_REFUSED errors, requiring a server restart. My local dev uses PHP's default file-based session handler, which is where the locking is most severe. Hosts using Redis or database-backed sessions would fare better, but it does highlight wider issues with the SessionStore approach as-is.

[kishore7snehil]

Since PHP's default file-based session handler is what most self-hosted WordPress installations use, and you've confirmed it causes server crashes on AJAX-heavy admin pages, I don't think we should ship this without at least warning admins at runtime.

[kishore7snehil]

Could you add an admin notice when "PHP Native Sessions" is selected? Something along the lines of:

"You have selected PHP Native Sessions for Auth0 session storage. The default PHP file-based session handler can cause performance issues with concurrent requests. For production use, configure a non-blocking session handler (Redis, Memcached, or database-backed) via session.save_handler in your PHP configuration."

This way we're not blocking the feature, but we're making sure admins don't hit the locking wall without any heads-up beyond the existing generic warning.