On Windows, wp cli update fails with "The downloaded PHAR is broken" because the PHAR verification runs wp --info, which calls get_mysql_binary_path() using /usr/bin/env which mysql — both /usr/bin/env and which don't exist on Windows, causing proc_open() to emit a fatal error.

Changes

• get_mysql_binary_path() — uses where mysql / where mariadb on Windows; takes only the first line of output since where can return multiple matches
• get_mysql_version() — uses force_env_on_nix_systems() which already strips /usr/bin/env on Windows
• get_sql_dump_command() / get_sql_check_command() — use where mariadb-dump / where mariadb-check on Windows
• All callers using the binary path in command strings — wrap with escapeshellarg() to handle paths containing spaces (e.g. C:\Program Files\MySQL\...\mysql.exe)

// Before
$mysql = Process::create( '/usr/bin/env which mysql', null, null )->run();

// After
if ( is_windows() ) {
    $mysql = Process::create( 'where mysql', null, null )->run();
} else {
    $mysql = Process::create( '/usr/bin/env which mysql', null, null )->run();
}

Tests

• features/utils.feature — verifies get_mysql_binary_path() returns a non-empty path on Linux with MySQL available (@require-mysql @skip-windows), and that it returns an empty string gracefully when simulating Windows via WP_CLI_TEST_IS_WINDOWS=1 (where where is unavailable on Linux)
• features/cli-info.feature — regression test that runs WP_CLI_TEST_IS_WINDOWS=1 wp cli info and asserts the command completes successfully with the MySQL binary: field present, directly covering the original crash scenario