Steps to reproduce:
1. Deploy zabbix-web-nginx-pgsql version 7.0.25 or older on Kubernetes without setting ZBX_SERVER_HOST environment variable
2. Upgrade to 7.0.26
3. Open the Zabbix frontend

Result:
"Zabbix server is not running" error is shown immediately after upgrade.

Root cause:
In 7.0.26, templates/entrypoints/lib/php.sh introduced a default value for ZBX_SERVER_HOST:

  7.0.25: export ZBX_SERVER_HOST=${ZBX_SERVER_HOST}   # empty if not set
  7.0.26: : "${ZBX_SERVER_HOST=zabbix-server}"         # defaults to "zabbix-server"

In zabbix.conf.php, ZBX_SERVER_HOST is only applied if non-empty:
  if (getenv('ZBX_SERVER_HOST')) { $ZBX_SERVER = getenv('ZBX_SERVER_HOST'); }

In 7.0.25, an unset ZBX_SERVER_HOST resulted in an empty value, so this condition was false
and the frontend fell back to its configured behavior.
In 7.0.26, the default "zabbix-server" is applied, which does not resolve in Kubernetes
environments where the service has a different name (e.g. "zabbix-zabbix-server").

Expected:
This breaking change should be documented in the release notes / upgrade guide,
with explicit instructions for Kubernetes users to set ZBX_SERVER_HOST to their
actual service name.

Workaround:
Explicitly set ZBX_SERVER_HOST to the correct Kubernetes service name in the
zabbix-web container environment variables.

Additional impact:
Prior to 7.0.26, leaving ZBX_SERVER_HOST unset allowed the frontend to connect
directly to the active HA node's IP address (read from the ha_node table in the
database). Setting ZBX_SERVER_HOST to a Kubernetes service name as a workaround breaks this behavior: the service load-balances across all replicas, including standby nodes that do not listen on port 10051. This makes it impossible to run multiple Zabbix server replicas in HA mode on Kubernetes without intermittent "Connection to Zabbix server refused" errors in the frontend.