Le 413 vient du serveur web, pas de votre code. La requête a été coupée avant d'atteindre PHP : voilà pourquoi rien n'apparaît dans le journal de l'application, et pourquoi relever upload_max_filesize seul ne change rien.

Nginx

# in http, server or location
client_max_body_size 64M;

sudo nginx -t && sudo systemctl reload nginx

La valeur par défaut est 1M. C'est la limite que presque tout le monde rencontre en premier.

PHP, et les deux valeurs

; 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 doit être PLUS GRAND que upload_max_filesize, car la requête transporte le fichier et le reste du formulaire. Mettez-les à égalité et un fichier pile à la limite échoue sans le moindre message utile.

Apache et LiteSpeed

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

Vérifiez ensuite ce qui est réellement chargé

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 ligne de commande et le serveur web lisent des fichiers ini différents. Une modification visible dans php -i mais pas dans le navigateur signifie que vous avez édité le mauvais — regardez aussi le répertoire des pools PHP-FPM.

Rechargez après chaque modification

sudo systemctl reload php8.3-fpm nginx
Sur l'hébergement EGPHP, ces limites sont fixées par offre et peuvent être relevées depuis le panneau. Voir aussi Une limite d'envoi qui ignore votre php.ini.