Keep the zram fallback until its replacement is installed

zram-generator creates no device at all when nothing configures one, so the
/etc copy is the only thing holding up swap until the vendor drop-in lands.
Removing it early costs a machine its zram entirely, not just its tuning.

The update pipeline installs packages before it runs migrations, so a packaged
machine always has the drop-in by then. A dev checkout does not: omarchy-update-dev
pulls migrations from a release the installed package has never seen, and no
ordering of the pipeline can produce a file that has not been built yet.
Checking for the drop-in is what makes the removal safe rather than well
sequenced.

The tests pinned the drop-in path to a fixture as well. Left at the real path
they would pass or fail on whether the machine running them happened to carry
the packaged copy.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

migrations/1785013000.sh

@@ -1,6 +1,7 @@
 echo "Move zram tuning to a vendor drop-in"
 
 zram_conf="${OMARCHY_ZRAM_CONF:-/etc/systemd/zram-generator.conf}"
+zram_dropin="${OMARCHY_ZRAM_DROPIN:-/usr/lib/systemd/zram-generator.conf.d/90-omarchy.conf}"
 
 # The tuning ships as /usr/lib/systemd/zram-generator.conf.d/90-omarchy.conf.
 # Drop-ins outrank the main config file, so a leftover /etc copy decides nothing
@@ -8,6 +9,13 @@ zram_conf="${OMARCHY_ZRAM_CONF:-/etc/systemd/zram-generator.conf}"
 
 [[ -f $zram_conf ]] || exit 0
 
+# Only once the replacement is on disk. zram-generator makes no device at all
+# when nothing configures one, so until the drop-in lands the /etc copy is the
+# only thing standing between this machine and no zram swap. The update pipeline
+# installs packages before it runs migrations, but a dev checkout carries
+# migrations from a release the installed package does not have yet.
+[[ -f $zram_dropin ]] || exit 0
+
 # Package-owned copies go away with their package on upgrade.
 pacman -Qo "$zram_conf" &>/dev/null && exit 0