Conflict with Uncode/Freemius

I host a few client sites who use the Uncode theme (which uses Freemius). There’s a currently a weird clash of versions between Uncode and Post SMTP, the result ends up causing /wp-admin/ to infinite redirect. Here’s the AI summary of the issue:
====

Environment: WordPress, Uncode theme 2.12.5 (bundles Freemius SDK 2.13.4 at themes/uncode/vendor/freemius/), Post SMTP 3.9.5 (bundles Freemius SDK 2.12.1 at plugins/post-smtp/freemius/). Reproduced on two unrelated sites with this plugin/theme pairing.

Symptom: The front end loads normally (HTTP 200). /wp-admin/ returns 302 to itself indefinitely — the browser spins forever. wp-login.php returns 200. Only admin requests are affected, because Uncode only initialises Freemius when is_admin() || wp_doing_cron() || WP_CLI.

Cause: Freemius resolves competing SDK versions by recording the newest in the fs_active_plugins option and calling fs_newest_sdk_plugin_first(), which reorders the active_plugins option so the bundle with the newest SDK loads first, then issues fs_redirect( $_SERVER['REQUEST_URI'] ) to reload the page. When the newest SDK is bundled in a theme, this can never succeed: fs_newest_sdk_plugin_first() only rewrites active_plugins, and WordPress loads all plugins before any theme. The redirect therefore repeats on every request. Observed fs_active_plugins in the broken state:

"newest": { "plugin_path": "uncode", "sdk_path": "../themes/uncode/vendor/freemius",
"version": "2.13.4", "in_activation": false }

Note that fs_redirect() at includes/fs-essential-functions.php uses a raw header( "Location: …" ) rather than wp_redirect(), so the response carries no X-Redirect-By header — which makes this loop unusually hard to attribute when debugging.

Possible SDK-side issue: in start.php, the redirect at line 370 is gated on the reorder having actually done something (if ( fs_newest_sdk_plugin_first() ) { … }), but the redirect at line 264 fires whenever class_exists( 'Freemius' ), without
checking the reorder's return value. The SDK already computes $is_newest_sdk_type_theme at line 274, so the theme case is known to it elsewhere.

Workaround (verified on both sites): overwrite plugins/post-smtp/freemius/ with the theme's 2.13.4 SDK and delete the fs_active_plugins option. A plugin then holds the newest SDK, the reorder becomes satisfiable, and /wp-admin/ returns a normal 302 to wp-login.php. This is undone by any Post SMTP update.

Requested fix (Post SMTP): update the bundled Freemius SDK to 2.13.4 or later.