Repair missing zram configuration before activating swap

[mostlydev]

On an ARM install upgraded to omarchy-settings 4.0.2-2, the zram default exists under /usr/share/omarchy/default/ but no configuration is installed where zram-generator reads it. Migration 1787669934.sh then starts systemd-zram-setup@zram0.service, fails with Device zram0 not found, and leaves the migration queue blocked. Rebooting does not restore the missing configuration.

Repair the existing migration so pending installations can reach the fix: copy the shipped default to /etc/systemd/zram-generator.conf only when no main configuration or drop-in exists at any supported configuration level, then reload systemd and start dev-zram0.swap. Starting the swap unit activates swap as well as setting up the device. Existing configuration, empty files, symlink masks, and active swap are preserved; an active device with missing persistent configuration gets the fallback without being restarted.

The fallback deliberately avoids an unowned /usr/lib file. A future package can restore its vendor drop-in without a file conflict, and that drop-in takes precedence over the fallback main configuration. This is a repair for the blocked migration, not a replacement for the package payload fixes in #353 or checkout wiring in #319. Users who already completed this migration still need the package fix. Related to #369 and #311.

Validation:

• Focused zram regression tests pass: missing and existing packages, absent configuration, custom configurations at all supported levels, empty/disabled/masked configurations, active swap with absent persistent configuration, repeated users, and package/configuration/activation failures.
• The installed zram-generator passes an unprivileged ZRAM_GENERATOR_ROOT integration test: no swap unit before repair; a swap unit with the setup dependency and swap.target link afterward.
• Independent QA and diff review pass for the focused change. Command metadata checks pass for 458 commands; parser-aware syntax checks pass.
• Local ./test/all: CLI passes; 255/256 shell test files pass on both this branch and untouched origin/quattro (291a6989). Both fail the same unrelated launch-about-test.sh assertion, a roomy window animates. No green local aggregate is claimed.
• Local ./tests/all has the same pre-existing piped --help assertion failure in test-mac-setup.sh on both revisions. Hosted PR CI passes test/all, tests/all, and Syntax + shellcheck.
• The hosted ARM installation fails the existing package-source assertion (hyprtoolkit installed=0.5.4-6 expected=0.5.4-5.1), unrelated to these two changed files. An independent unchanged-quattro run on my fork reproduces the identical failure. Isolating the existing package-selection fix from Integrate Apple Silicon stabilization fixes for 4.0.3rc1 #377 yields a passing ARM run, including the real-Pacman regression and fresh/repeat installation, with all three selected compositor package versions retained. That comparison branch does not include this zram change; it establishes the independent installer defect and its existing fix.

No privileged migration or swap changes were run on the host as part of testing this PR.