After re-reading about the water being spilled and @Ocka's response regarding keys being stuck, along with your mention of tapping the esc key to get the boot process to proceed; I tend to agree here. I think that the esc key on your built-in keyboard might be a very likely cause with the spamming of those messages, or possible halt of the normal boot process.
I've noticed in the past that pressing or holding the esc key causes the system to display boot messages or errors that would otherwise be hidden during the boot process. Definitely recommend troubleshooting that. The caps-lock key doesn't seem like it could be part of the equation here, but I read that some systems/distros can use the caps-lock key input to show certain error conditions as well, like kernel panics, etc. Though, I don't know if that is the case for Zorin.
The xinput disable command that you used to disable the internal keyboard only applies to the running session of the operating system, after the boot process has completed.
Even though you're using an external keyboard, it may be possible that your damaged keyboard (internal, non-working) is being probed by the boot process so that it can make sure you have the ability to interact with the system during boot.
If the boot process doesn't see the external keyboard you are now using, or finds the non-working internal keyboard first, that might be what's holding up the boot process (looping) at the same place, preventing boot or further attempts to detect a different device (external keyboard).
The messages you see in the first screenshot show that the fsck or e2fsck filesystem checking tools are being run to make sure there are no errors or corruption of the filesystem.
The clean message is a good thing, but that doesn't mean there aren't errors or issues with accessing the mounted filesystem on the disk.
The recovering journal message shows that fsck or e2fsck is recovering the journal of the filesystem, which is a normal part of the filesystem check process during boot.
I don't know how many times the filesystem check process is being initiated, but it seems like after they complete is when the halt/error happens - and maybe that's due to the fact that the interface probe is failing.
When the system checks for ways in which the user can interface with the machine, that process usually happens after the initial filesystem checks you see happening: clean...files...blocks...journal recovery.
Once the basic system components are loaded and initialized, the kernel will probe for hardware devices and initializes drivers to allow them to be used. That includes input devices like keyboards, mice and touchpads.
Here is where I think the issue might be, because the system will usually wait a few seconds during boot process for any input device to be detected before proceeding with the login prompt - which also seems to not be happening based on your second screenshot with the Failed to start show Plymouth Boot Screen error.
Running fsck or e2fsck on a mounted filesystem should be avoided. This is because those tools are designed to check and repair filesystems when they are not in use, and when a filesystem is mounted, it is in use by the operating system and other applications. That said, you probably don't have to worry about this since you can't get past a certain point in the boot process; I just feel like it is worth mentioning. Also worth mentioning; in lieu of fsck, e2fsck is the preferred tool to use for ext2, ext3, and ext4 filesystem checks and repairs.
One thing you might try is to boot into recovery mode by holding the Shift key while booting, which should give you a GRUB bootloader menu containing the recovery mode option. Using the recovery mode's command-line interface can allow you to run commands to check the filesystem manually, rather than allowing the boot process to automatically move through its checks, including attempting to probe for interface devices and start the graphical user interface.
When you boot into recovery mode, the interface probe mentioned above has likely already happened because it is part of that early boot process.
That said: since recovery mode usually uses a minimal set of drivers and services, it's possible that the keyboard issue might not present in this mode. You might try this to rule out a keyboard interface detection issue and any filesystem issues that might cause failure to boot. While in this mode, you can run e2fsck to check and repair the filesystem manually.
You can, and probably should, also try this by booting from a live USB or CD and running the following command: sudo e2fsck /dev/sda6.
Running the e2fsck command while using a Live USB or with the hard drive attached to another computer can also help in identifying and fixing any filesystem errors that might be causing the boot process to fail.
By running e2fsck on the hard drive from a different environment, you can rule out or identify any hardware or software issues that might be preventing the boot process from completing successfully. Additionally, using a Live USB or a different computer to run e2fsck can help in accessing the hard drive's filesystem without any restrictions or limitations that might be present when running e2fsck on a mounted filesystem.
)