Cache breaks WordPress loopback/scrape mechanism in code editors

Run into a strange issue today while I was quickly testing some code changes online.
I've set up a brand new, clean site yesterday from cPanel and started experimenting with some stuff using the WP code editor and editing the active theme and a plugin. Went to sleep, next day the "Update File" button was broken (see image).

I dived really deep into how WP does these loopback/scrape checks/requests when editing live themes and plugins, and I figured out, the issue was that my cPanel automatically added and enabled LSCache on this site overnight (with default, caching enabled) and LSCache broke WP loopback tests by caching the home page. When I disabled the plugin, everything worked again.

## About WP loopback/scrape
When you edit a live plugin/theme in the WP code editor, WP checks if you "whitescreened" yourself by applying the changes and checking /wp-admin and the home page in two, synchronous `wp_remote_get` calls - and if it detects any php errors, it reverts the file and throws an error in the same admin ajax process. WP opens the /wp-admin and the home page with `wp_remote_get` and adds `wp_scrape_key` and a nonce as url parameters (like: `https://example․com?wp_scrape_key={randomhash}&wp_scrape_nonce={nonce}`) - and if these parameters are present, WP simply echos "needle" strings like `###### wp_scraping_result_start:$key ######` in the response. WP uses these "needles" to wrap either a "success" message, or the caught PHP errors (to report them to the user), but if the main save process can't even find these "needles" in the output, it throws the "loopback request failed" error and reverts the file.

Sources:
https://github.com/WordPress/wordpress-develop/blob/6.8.3/src/wp-includes/load.php#L1840-L1901
https://github.com/WordPress/wordpress-develop/blob/6.8.3/src/wp-admin/includes/file.php#L584-L628

## About the issue
Figured out the error was happening because LSC cached my home page and the "needle" strings were not showing up for the `wp_remote_get` verification requests for the ajax save process. However, what I don't really get is 1) why this never caused an issue for anyone if LSCache has no cache exclusions for url containing `wp_scrape_key`? or 2) why this started causing an error for me now?

--

Start with the linked WordPress references in wp-includes/load.php and wp-admin/includes/file.php, then reproduce the code-editor save check with LiteSpeed Cache enabled. Compare loopback responses for requests containing wp_scrape_key and verify the behavior with the cache enabled and disabled; done means the editor's loopback verification works reliably when caching is active.

Written by the indexing model from the issue text.