The following might be lies, so take it with a grain of salt til someone more qualified comments:
When your scripts are running, they are running from the perspective of the client; however, the file system you see is not the actual file system on the disk of the client; it’s a temporary file system that comes from the PXE file/kernel you boot. So when you operate on “/etc/fstab”, you are making a change to the fstab of something that is running memory, and thus no changes persist. If you really want to operate on files on the host, you need to mount the disk device. This is not an entirely fool-proof way, but for my scripts, I mount /dev/sda to /mnt and then can operate on files within that and those changes end up in the host. So for your example, you’d need to do something like this in your script:
#!/bin/bash
mount -t ext4 /dev/sda1 /mnt
ORIGINAL=$(grep -v '#' /mnt/etc/fstab | grep swap | cut -d ' ' -f1 | cut -d '=' -f2)
....
/dev/sda has worked well enough for me, though I am sure there are situations in which it would fail.
Secondly, to the heart of your issue, I believe your analysis is correct in that the UUID issue isn’t something you should be fixing in postdownload scripts. UUID’s, if I understand correctly, are unique, based on the hardware ID of the device. To my understanding, FOG should be handing that during the imaging process (similarly to how it handles growing the file system).