Ship zram tuning as a vendor drop-in

pacman checks file conflicts during transaction prepare, so the --overwrite
entry added alongside /etc/systemd/zram-generator.conf never got to run: the
copy of omarchy-update-system-pkgs driving the upgrade is the one already on
disk. Every machine carrying archinstall's copy aborted the transaction.

zram-generator.conf(5) reserves /etc for the local admin and has vendors ship
snippets under /usr/lib/systemd/zram-generator.conf.d/, where drop-ins outrank
the main config file. Nothing collides, and the tuning wins whether or not
archinstall's file is still around.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LjeyQZsNBxqyYy9z8KaKm7

etc/systemd/zram-generator.conf

@@ -1,12 +0,0 @@
-# Compressed swap in RAM. zstd averages around 3:1, so the worst case for a
-# full device is roughly a third of the size below.
-#
-# The generator's own default caps this at 4G, which sends machines with a lot
-# of memory to the disk swapfile far earlier than they need to go.
-[zram0]
-zram-size = min(ram / 2, 8192)
-compression-algorithm = zstd
-
-# Above the pri=0 that omarchy-hibernation-setup gives the disk swapfile, so
-# zram absorbs everything until it's full.
-swap-priority = 100