Correct misdiagnosis: zpool sysfs parameter doesn't exist on some kernels

[modem7]

Summary

Corrects a wrong root-cause diagnosis from the previous fix (#18).

What was wrong: I misread /sys/kernel/security/lockdown's output format. The bracketed value ([none] integrity confidentiality) is the currently active mode — [none] means lockdown is off. I read it backwards and shipped a fix (modprobe zsmalloc) plus warning text blaming "kernel lockdown / Secure Boot," neither of which was the actual cause on pbs, samwise, or frodo.

Actual cause, confirmed via diagnostics pasted from all three real hosts: /sys/module/zswap/parameters/zpool doesn't exist on this kernel (7.0.14-8-pve) at all. ls only shows accept_threshold_percent, compressor, enabled, max_pool_percent, shrinker_enabled. dmesg shows zswap loading fine at boot (zswap: loaded using pool zstd / ... using pool lzo) with zero mention of zpool, despite zswap.zpool=zsmalloc being on the kernel cmdline. This kernel only compiles in zsmalloc — there's nothing to select, so the sysfs knob was never registered. Not a permission block, not lockdown — just a parameter that doesn't exist here.

Fix:

• Step 3 checks the file exists before attempting to write to it, instead of always trying and treating the inevitable failure as a lockdown symptom.
• Step 5 treats a missing zpool file as "not applicable to this kernel" rather than a configuration mismatch.
• Result: samwise's actual live state (enabled: Y, compressor: zstd, no zpool file) now correctly reports as fully configured, instead of the false "caveat" warning from the previous version.

Test plan

• bash -n syntax check passes
• Traced through against actual diagnostic output pasted from pbs, samwise, and frodo — confirms this is the real cause on all three
• Not re-run live end-to-end (no test VM currently available) — logic change only, reasoned through against real captured data instead