The most likely issue is that your 'mkinitcpio' made the initramfs without the [encrypt] hook. To check if that is so, perform a live boot and and look at '/etc/mkinitcpio.conf'.
So you now have to
chroot into your machine, add that hook in '/etc/mkinitcpio.conf' and run
# mkinitcpio -p linux-lts
This has nothing to do with Artix specifically. They build the kernel with LUKS support like 99.9% of distros. I'm on the latest testing repos running full disk encryption just fine myself. What physkets said seems like the most likely fix to me although I don't know why your [encrypt] hook would suddenly disappear from your mkinitcpio.
I'm using LUKS too, (4.9.x and 4.13.x kernel) and I've no problem; your situation is very strange.
I don't know if you have never chroot-ed for a LUKS partition, but this is the procedure to chroot for a LUKS volume (I'm using LUKS from a long time and I got, in the past, the needed to manage the LUKS partition).
1) Boot with a liveUSB
2) Open a Terminal session
3) Identify the hd partition: lsblk
In this example I suppose that:
/dev/sda1 is the /boot partition
/dev/sda2 is the LUKS encrypted partition
NOTE: replace sda1 or sda2 with the partition name that you get with the lsblk command
$ su
$ cryptsetup open --type luks /dev/sda2 root # where sda2 is the encrypted device
$ mount /dev/mapper/root /mnt
$ mount /dev/sda1 /mnt/boot # mount here the boot partition
$ mount -t proc proc /mnt/proc
$ mount -t sysfs sys /mnt/sys
$ mount -o bind /dev /mnt/dev
$ mount -o bind /run /mnt/run
$ mount -t devpts pts /mnt/dev/pts
$ cp /etc/resolv.conf /mnt/etc/resolv.conf
$ chroot /mnt
4) now you can use all the command as if this is your new root environment
5) insert the encrypt parameter in the mkinitcpio.conf
$ mkinitcpio -P
HINT: if you are using BTRFS, probably the installation program have generated 2 subvolume: @ and @home. If so you must modify all the reference from /mnt to /mnt/@. For example:
mount -t proc proc /mnt/proc become mount -t proc proc /mnt/@/proc
Good Luck :)