fix(health): resolve SYSTEM time_zone and skip check on 6.7 - #479

1. Why is this change necessary?

The sql_time_zone health check compares @@time_zone with +00:00 and UTC only. It has two problems:

• If MySQL runs with time_zone = SYSTEM (the server default), the check warns even when the host itself runs in UTC. On Shopware 6.6 this happens as soon as SQL_SET_DEFAULT_SESSION_VARIABLES=0 is set, which is the setup the sql_set_default_session_variables recommendation asks for.
• On Shopware 6.7, MySQLFactory always runs SET @@session.time_zone = '+00:00' on connect. Read through Shopware's connection, @@time_zone is therefore always +00:00, so the check can never fire there.

2. What does this change do, exactly?

• MysqlSettingsChecker::checkTimeZone() returns early on Shopware >= 6.7, using the same version gate as checkCheckDefaultEnvironmentSessionVariables().
• It reads @@time_zone and @@system_time_zone together. A value of SYSTEM is resolved to the host time zone before the comparison, and the warning shows both, e.g. SYSTEM (CEST).
• Etc/UTC is added to MysqlSettingsChecker::MYSQL_TIME_ZONES.
• The sql_time_zone recommendation text now says "(Relevant before Shopware 6.7.)", like the sql_set_default_session_variables one.

@@system_time_zone is an abbreviation, so a host that reports GMT still gets the warning.

3. Describe each step to reproduce the issue or behaviour.

Setup: Shopware 6.6 with SQL_SET_DEFAULT_SESSION_VARIABLES=0, no default-time-zone in the MySQL config (so @@time_zone is SYSTEM), and the MySQL host running in UTC (SELECT @@system_time_zone returns UTC).

1. Open Settings → Tools → System-Status, section "Performance recommendations".
2. Before: "MySQL value time_zone" warns with current value SYSTEM.
3. After: no time_zone warning.
4. Switch the MySQL host to a non-UTC zone (e.g. TZ=Europe/Berlin) and restart MySQL. After: the warning shows SYSTEM (CEST).
5. On Shopware 6.7 the time_zone row never appears, before or after, because Shopware sets the session time zone itself.