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

default/systemd/zram-generator.conf.d/90-omarchy.conf

@@ -0,0 +1,12 @@
+# 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