Handle legacy swap parts

[h8d13]

From the discord, unfortunately no full trace-back or log file.

Steps to reproduce are simple:

1. Install a first time with legacy swap partition (not zram)
2. Open the installer again ([SWAP] shows as mountpoint which is from lsblk info methods)
3. Display bug + mounting should/will fail

Probably we need

1. Filter [SWAP] when parsing lsblk output in LsblkInfo
2. Handle unmount for swap using swapoff
3. Helper for swapoff similar to swapon

[VykosMolt]

I can take a look at this.

Confirmed reproducible on current master: lsblk reports [SWAP] in both mountpoint and mountpoints for an active swap partition, and LsblkInfo parses that straight into a Path. So umount() sees a non-empty mountpoints list, skips its early return, and runs umount -R '[SWAP]' instead of swapoff, which is also how [SWAP] ends up displayed as a mountpoint.

Noting overlap so I'm not duplicating: #4536 adds a private _swapoff_path() in disk/utils.py, but for post-install teardown of the layout archinstall just created rather than pre-existing swap discovered by lsblk, and it doesn't touch the parsing side. If a helper is needed here I'll make it a public one next to swapon() so that PR can reuse it rather than us ending up with two.

I'll work on a scoped fix with regression coverage.

[h8d13]

I kind of gave up of on tear-down so feel free to take both (in seperate PRs) :D

As to:

which is also how [SWAP] ends up displayed as a mountpoint.

Believe it could simply be skipped