413 comes from the web server, not from your code. The request was cut off before PHP was reached, which is why nothing appears in the application log and why raising upload_max_filesize on its own changes nothing.

Nginx

# in http, server or location\nclient_max_body_size 64M;\n\nsudo nginx -t && sudo systemctl reload nginx

The default is 1M. That is the limit almost everyone hits first.

PHP, both of them

; php.ini\nupload_max_filesize = 64M\npost_max_size = 68M       ; must exceed upload_max_filesize\nmemory_limit = 128M\nmax_execution_time = 300
post_max_size must be LARGER than upload_max_filesize, because the request carries the file plus the rest of the form. Set them equal and a file at exactly the limit fails with no useful message at all.

Apache and LiteSpeed

# .htaccess\nLimitRequestBody 67108864\nphp_value upload_max_filesize 64M\nphp_value post_max_size 68M

Then confirm what is actually loaded

php -i | grep -E 'upload_max_filesize|post_max_size'   # the CLI, which may differ\n# and from the web, in a temporary file:\n# <?php echo ini_get('upload_max_filesize');
The CLI and the web server read different ini files. A change that shows up in php -i and not in the browser means you edited the wrong one - check the PHP-FPM pool directory as well.

Reload after every change

sudo systemctl reload php8.3-fpm nginx
On EGPHP hosting these limits are set per plan and can be raised from the panel. See also an upload limit that ignores your php.ini.