Fix the contrib path guard in 'settings.fast404.php' and cover it with a test

[AlexSkrypnyk]

Summary

web/sites/default/includes/modules/settings.fast404.php guards its entire body on a path that Composer never creates, so the block never executes on a consumer site. Every fast404_* setting the file defines is dead, and fast404_preboot() is never called.

Details

The guard and the include both look for fast404/fast404.inc:

if (file_exists($contrib_path . '/fast404/fast404.inc')) {
  // ...
  include_once $contrib_path . '/fast404/fast404.inc';
  fast404_preboot($settings);
}

The contributed module is drupal/fast_404, with an underscore. composer.json maps type:drupal-module to web/modules/contrib/{$name}, so it installs to web/modules/contrib/fast_404/. $contrib_path . '/fast404/fast404.inc' resolves to a path that does not exist, whether or not the module is installed.

Expected: a consumer site that runs composer require drupal/fast_404 gets these settings applied and the preboot 404 handler active.

Actual: nothing happens. The site keeps rendering its full themed 404 page, and there is no signal that the settings file did nothing.

This surfaced on a consumer site where the 404 page was measured at 35.5% of all PHP time over a 7 day window. The settings file was present and correctly written, the module was absent, and the guard would not have fired even after installing it.

A test should exist

tests/phpunit/Drupal/SwitchableSettingsTest.php already covers most of web/sites/default/includes/modules/. There are cases for clamav, config_split, environment_indicator, redis, shield, reroute_email, stage_file_proxy, mail collector and trusted hosts.

settings.fast404.php has no test. Its body is also wrapped in @codeCoverageIgnoreStart and @codeCoverageIgnoreEnd, so neither the test suite nor the coverage report can show that the block is unreachable. A file can carry a broken guard indefinitely under those two conditions.

A case in the existing SwitchableSettingsTest pattern, asserting the fast404_* settings are present when the module directory exists and absent when it does not, would have caught this.

Suggested fix

1. Correct both occurrences of the path to fast_404/fast404.inc.
2. Add a testFast404() case to SwitchableSettingsTest covering both the module-present and module-absent branches.
3. Reconsider the @codeCoverageIgnore wrapper on this file, since it is what hides the block from coverage.

Related, worth deciding separately

The module's headline feature is serving a static HTML file as the 404 response, via $settings['fast404_HTML_error_page'] combined with $settings['fast404_HTML_error_all_paths']. Neither appears in the scaffolded file, so a consumer who fixes the path still gets only the bare inline fast404_html string on file extension misses. Whether Vortex ships those 2 settings commented out is a separate decision from the path bug, but this file is where they would live.