W3TC should not create master.php if it already exists

[ckeeney]

I run WP in a containerized environment on Kubernetes and this morning I updated WP Core (from 6.8.1 to 6.8.2) and W3TC (from 2.8.9 to 2.8.12).
I have master.php mounted via a Kubernetes volume, and this has worked for many months. However, W3TC is now trying to overwrite my master.php file, but it is failing fatally because master.php is not writable.

Is there a flag I can add to tell W3TC to not attempt to create this file, or can W3TC not try to create this file if it already exists?

W3TC tries to overwrite this file when I merely look at the plugins page. I "solved" this by deactivating W3TC from WP CLI, but I obviously want the functionality of the plugin (I pay for the premium version).

Once the plugin was deactivated, the plugins page would load fine, but attempting to activate the plugin from either the plugins dashboard or WP CLI both had the same fatal error pasted below.

I was able to re-activate the plugin by removing my own master.php and letting W3TC create its own master.php, and then re-mounting my master.php, but when I do that the plugins page is broken again, and none of the pages under the "Performance" navlink on the side work either.

When seeking help with this issue, you may be asked for some of the following information:
WordPress version 6.8.2
Active theme: TNI Theme (API Endpoints Extravaganza) (version 1.24.2152017.bugfix)
Current plugin: W3 Total Cache (version 2.8.12)
PHP version 8.4.13

Error Details

An error of type E_ERROR was caused in line 460 of the file /var/www/html/web/app/plugins/w3-total-cache/Util_File.php. Error message: Uncaught Exception: Can't write to file /var/www/html/web/app/w3tc-config/master.php in /var/www/html/web/app/plugins/w3-total-cache/Util_File.php:460
Stack trace:
#0 /var/www/html/web/app/plugins/w3-total-cache/ConfigUtil.php(110): W3TC\Util_File::file_put_contents_atomic()
#1 /var/www/html/web/app/plugins/w3-total-cache/ConfigCompiler.php(275): W3TC\ConfigUtil::save_item()
#2 /var/www/html/web/app/plugins/w3-total-cache/Config.php(505): W3TC\ConfigCompiler->save()
#3 /var/www/html/web/app/plugins/w3-total-cache/Generic_Environment.php(43): W3TC\Config->save()
#4 /var/www/html/web/app/plugins/w3-total-cache/Root_Environment.php(40): W3TC\Generic_Environment->fix_on_wpadmin_request()
#5 /var/www/html/web/app/plugins/w3-total-cache/Generic_Plugin_Admin.php(1200): W3TC\Root_Environment->fix_in_wpadmin()
#6 /var/www/html/web/wp/wp-includes/class-wp-hook.php(324): W3TC\Generic_Plugin_Admin->admin_notices()
#7 /var/www/html/web/wp/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#8 /var/www/html/web/wp/wp-includes/plugin.php(517): WP_Hook->do_action()
#9 /var/www/html/web/wp/wp-admin/admin-header.php(313): do_action()
#10 /var/www/html/web/wp/wp-admin/plugins.php(637): require_once('...')
#11 {main}
thrown

[ckeeney]

After digging into this further, W3TC tries to overwrite the file if the version in the config file mismatches the current instance of W3TC. This feels a bit heavy-handed, but ideally when this fails to write the file, it could have a nicer error message that the config file is out of date.