What bug does this fix? Explain your changes.

This PR fixes a fatal error that occurs when updating WPGraphQL options via /wp-admin/options.php with empty string values.

What the bug was:
When a user navigates to /wp-admin/options.php and updates a WPGraphQL option (such as graphql_experiments_settings or graphql_general_settings) with an empty string value, WordPress triggers a fatal TypeError.

How it was manifesting:
The error message was:

PHP Fatal error: Uncaught TypeError: WPGraphQL\Admin\Settings\SettingsRegistry::sanitize_options(): Argument #1 ($options) must be of type array, string given

This occurred in the WordPress admin when submitting the options form, causing the entire admin dashboard to crash.

What the root cause was:
The sanitize_options() method in SettingsRegistry had a strict array type hint for its parameter. However, when WordPress calls the sanitization callback via the sanitize_option_{$option_name} filter (which happens when updating options through /wp-admin/options.php), it can pass the raw value directly - which may be a string (like an empty string '') rather than an array. This type mismatch caused the fatal error.

How your fix addresses it:
The fix modifies sanitize_options() to:

1. Accept mixed type instead of strict array type
2. Check if the input is an array before processing
3. Return non-array values unchanged (since they don't need array-based sanitization)
4. Only process array values through the existing sanitization logic

This ensures compatibility with WordPress's sanitization filter behavior while maintaining the existing functionality for array-based settings.

Does this close any currently open issues?

Closes #3439

Testing Strategy

This PR follows the preferred commit structure for bugfixes:

1. First commit: Added a failing functional test (SettingsRegistryOptionsPageCept.php) that reproduces the bug by submitting the options form with empty string values
2. Second commit: Implemented the fix in SettingsRegistry::sanitize_options() to handle non-array values gracefully

This approach demonstrates that:

• The bug exists (test fails before the fix)
• The fix resolves the issue (test passes after the fix)
• The fix doesn't break existing functionality (all other tests continue to pass)

Test Results

• Failing test added: https://github.com/wp-graphql/wp-graphql/actions/runs/19439968718
• Fix implemented: https://github.com/wp-graphql/wp-graphql/actions/runs/19440029798/

Before/After Examples

Before (Buggy Behavior):

1. Navigate to /wp-admin/options.php in WordPress admin
2. Update graphql_experiments_settings or graphql_general_settings with an empty string value
3. Submit the form
4. Result: Fatal error page displayed, admin dashboard crashes

After (No error):

1. Navigate to /wp-admin/options.php in WordPress admin
2. Update graphql_experiments_settings or graphql_general_settings with an empty string value
3. Submit the form
4. Result: Form Saves as expected