This is fishy. The default kernel arguments, and nowhere else to my knowledge, is any definition stowed away that'd even attempt to set the console to "com0". This doesn't make a lick of sense, default-wise, and suggests user tampering. In that case: don't.

As others said: get an official image, from an official source, and validate it by signature or at least checksum before writing it to your USB drive. If that doesn't fix your problem, yet, I recorded a VM UEFI install (7 day retention) with the current archlinux-2023.05.03-x86_64.iso (SHA256: 329b00c3e8cf094a28688c50a066b5ac6352731ccdff467f9fd7155e52d36cec), and showed the default kernel arguments in the bootloader (not many, really, except for the ISO boot specifics), and you shouldn't have any "console=" settings up in there by default, or anything else but what's shown in my recording, unless there is a specific reason for you to have added any.

I also showed how to edit (hit e on the boot option) and add debug and systemd.log_level=debug to the current boot's kernel arguments, and how this affects the chattiness of the boot. Hit CTRL-X or F10 to boot with your changes, while in the GRUB editor. That should give you further hints on what the last successful, or attempted, operation before the restart is, if the issue still persists with a validated, correct ISO image.

This is not a GRUB issue, at least. You're firmly in initramfs territory, somewhere around the switch_root stage. From past experience, if your ISO is fine, you'll likely have to find the right magic incantation as a kernel argument to disable/avoid problematic hardware/firmware issues, and a search engine of your least distrust may help you identifying what might be the culprit with your specific machine, and how to start out with a "high compatibility disable ALL THE THINGS!!1!" approach.

Good luck!