“Hide WP Version” breaks ?ver= caching, blanks Jetpack/React admin

Bug: "Hide WP Version" strips ?ver= from every enqueued script/style site-wide, breaks browser cache-busting, causes blank screens on React-based admin pages

Version tested: 1.1.17
WordPress: 7.0
Host: Pressable/Atomic
Triggering page: My Jetpack (admin.php?page=my-jetpack), but this isn't Jetpack-specific — any admin screen built on @wordpress/data will be affected.

Symptom:
With Atlant active, My Jetpack's settings screen renders blank. Console shows cascading errors from wp-includes/js/dist/private-apis.min.js ("You tried to opt-in to unstable APIs…") and "isShallowEqual is not a function" originating in data.min.js. Deactivating Atlant fixes it immediately; reactivating breaks it again, 100% reproducible.

Root cause:
includes/modules/LoginProtection.php, inside init(), gated by get_option('aswp_hide_wp_version', true):

add_filter( 'script_loader_src', [ CLASS, 'remove_version_query' ], 15, 1 );
add_filter( 'style_loader_src', [ CLASS, 'remove_version_query' ], 15, 1 );

remove_version_query() unconditionally strips the ver query arg via remove_query_arg('ver', $src) from every single enqueued script and style on the entire site — not scoped to front-end-only, not scoped to core files, just everything, including admin pages.

This breaks the cache-busting mechanism that ver query strings exist for. wp-includes/js/dist/*.min.js files ship with long-lived Cache-Control headers, which is normal and expected — they're meant to be safely cached indefinitely because the ver string changes whenever the file content does. Once that query string is gone, the browser has no way to know when to refetch. So if a browser ever cached one of those files under its bare (no-query-string) URL — which it will, since that's the only URL Atlant ever serves it under — it'll keep serving that stale copy indefinitely, even across WordPress core or Jetpack version updates that change the file's actual content.

The result on a real site: an old cached copy of @wordpress/data sitting next to freshly-fetched @wordpress/rich-text and @wordpress/block-editor, which are not safe to mix across versions. That's exactly what produces the private-apis opt-in errors and isShallowEqual crash — a version-incompatible mix of the same package family.

Confirmed by: diffing full page source between working (Atlant off) and broken (Atlant on) states — every enqueued asset on the page loses its ?ver= only in the broken state, nothing else differs. Then confirmed definitively by hard-reloading (cache disabled) with Atlant still active — page renders correctly, proving it's a stale local browser cache issue caused by the missing query string, not a server-side block, REST issue, or any of the other modules (WAF, Honeypot, Custom Login URL, REST API Policies, Security Headers were all individually ruled out first).

Suggested fix: the actual goal (not disclosing the WP version) is already fully achieved by the remove_action('wp_head', 'wp_generator') and add_filter('the_generator', '__return_empty_string') calls a few lines above this in the same function. The script_loader_src / style_loader_src stripping doesn't add meaningful protection (the version is still inferable from core file checksums, readme.html, feature availability, etc.) and actively breaks cache invalidation for every site running this option at its default of true. Recommend removing those two filters entirely, or at minimum scoping them to !is_admin() so admin-side React apps aren't affected.

Happy to provide the full console trace / page source diff if useful.