Site Health: Falsely reports "OPcode cache is not-configured" due to restricted opcache_get_status() on ALL-INKL hosting

[rkendlbacher]

### Environment:

• Hosting Provider: ALL-INKL.COM (Germany, Shared Hosting Environments)
• WordPress Version: 6.x / 7.x
• PHP Version: PHP 8.1 / 8.2 / 8.3 / 8.4

### Steps to reproduce:

1. Host a standard WordPress installation on a shared hosting server at ALL-INKL.COM.
2. Verify via phpinfo() that PHP OPcache (opcache.enable) is actively running and working in the background.
3. Navigate to "Tools" -> "Site Health" inside the WordPress Dashboard.

### Why the hosting provider restricts this function (Technical Background):
According to the official technical policy of ALL-INKL.COM regarding shared server environments, the PHP function opcache_get_status() is strictly restricted or disabled by default.

• Information Disclosure / Cross-User Visibility: Because OPcache uses a shared memory infrastructure, letting any user trigger opcache_get_status(true) would expose an array containing the absolute file paths, directory structures, and names of ALL cached PHP scripts across different users on that same physical hardware.
• Data Privacy: To maintain customer isolation and prevent massive security/privacy leaks in shared environments, the provider forces opcache_get_status() to return false or blocks it entirely. However, the bytecode cache itself is fully operational and speeds up the execution of the PHP scripts normally.

### Expected result:
WordPress Site Health should recognize that OPcache is active by validating ini_get('opcache.enable'). If a shared hosting environment restricts diagnostic status functions due to standard security/isolation patterns, WordPress should downgrade this to a neutral info notice or state that extended statistics are hidden by the hoster, instead of flagging it as a critical malfunction.

### Actual result:
Site Health displays an alarming critical performance warning: "The OPcode cache is not-configured or disabled."

This issue leads to massive uncertainty and confusion among users and administrators who maintain the WordPress installation, as they are led to believe their server is poorly optimized when it is actually configured correctly.

This causes unnecessary support tickets for hosting providers and frustration for non-technical users.

### Proposed Solution:
Adjust the check inside wp-admin/includes/class-wp-site-health.php. Before throwing a critical failure based solely on opcache_get_status(), verify whether ini_get('opcache.enable') returns true. If the INI flag is active but the status array is blocked or returns false, display an educational notice regarding provider-level restrictions instead of an error.

[siliconforks]

I think this is the same issue as #65395?