El 413 viene del servidor web, no de tu código. La petición se cortó antes de llegar a PHP, y por eso no aparece nada en el registro de la aplicación y por eso subir upload_max_filesize por sí solo no cambia nada.

Nginx

# in http, server or location
client_max_body_size 64M;

sudo nginx -t && sudo systemctl reload nginx

El valor por defecto es 1M. Ese es el límite con el que casi todo el mundo choca primero.

PHP, y los dos valores

; php.ini
upload_max_filesize = 64M
post_max_size = 68M       ; must exceed upload_max_filesize
memory_limit = 128M
max_execution_time = 300
post_max_size debe ser MAYOR que upload_max_filesize, porque la petición lleva el archivo más el resto del formulario. Ponlos iguales y un archivo justo en el límite falla sin ningún mensaje útil.

Apache y LiteSpeed

# .htaccess
LimitRequestBody 67108864
php_value upload_max_filesize 64M
php_value post_max_size 68M

Después confirma qué se ha cargado de verdad

php -i | grep -E 'upload_max_filesize|post_max_size'   # the CLI, which may differ
# and from the web, in a temporary file:
# <?php echo ini_get('upload_max_filesize');
La línea de órdenes y el servidor web leen archivos ini distintos. Un cambio que se ve en php -i y no en el navegador significa que editaste el que no era; mira también el directorio de pools de PHP-FPM.

Recarga tras cada cambio

sudo systemctl reload php8.3-fpm nginx
En el alojamiento de EGPHP estos límites se fijan por plan y pueden subirse desde el panel. Consulta también Un límite de subida que ignora tu php.ini.