LintabOS 0.3.16

LintabOS 0.3.16 (pre-release)

The last three bugs in one chain, all found live on the same real Duet 3, in the space of about an hour: LinWinMod
"Open Windows files" had never actually worked on this kernel, for three separate, compounding reasons.

1. ntfsresize used a bare subprocess.run, bypassing the PATH fix 0.3.5 made elsewhere

lintab.bitlocker.probe() - the health check LinWinMod, WinTermMod and the read-write "Windows files" toggle all
run before touching a drive - called ntfsresize directly, never through disks.resolve_executable(). On a plain
desktop session whose PATH doesn't include /usr/sbin (where ntfsresize actually lives), that's a bare
FileNotFoundError - the real, literal cause of "can't find ntfsresize." The PATH fix 0.3.5 made for sfdisk
elsewhere was never applied to this file. Fixed: probe() now resolves ntfsresize the same way.

2. The ntfs3 kernel module doesn't exist on this kernel at all

With ntfsresize now actually found and run, the next real error was ERROR(13): ... Permission denied -
itself just a sign the unprivileged check structurally can't read the raw device (expected; see #3 below) - which
led to testing the full mount path directly, and finding: modprobe ntfs3 reports "Module ntfs3 not found in
directory /lib/modules/7.1.13+deb13-amd64". Debian's own kernel package does not build or ship the newer in-kernel
NTFS driver at all. lintab.winfiles.mount_fstype() has always requested exactly that nonexistent driver
(mount -t ntfs3), so every attempt to mount the Windows drive through the fstab entry this project manages has
always failed with mount: unknown filesystem type 'ntfs3' - regardless of anything else being fixed.

Confirmed live: mount -t ntfs (not ntfs3) dispatches through the standard /sbin/mount.ntfs -> mount.ntfs-3g
helper convention to this project's own existing ntfs-3g dependency - no kernel module involved at all. Fixed:
mount_fstype() now requests ntfs. Confirmed on the real tablet: the fstab entry now reads ntfs instead of
ntfs3, and mount /media/windows actually succeeds, read-write, listing the real Windows C: drive.

3. The unprivileged pre-flight health check could never pass, and treated that as a hard block

Even with ntfsresize found, the health check in bitlocker.probe() needs to open the raw partition device to
read NTFS's own dirty/hibernation flags - exactly the same raw-device permission wall read_disk() hit in 0.3.15,
just for a different tool. Unprivileged, this check can never succeed - not because of anything wrong with the
volume, but because it was never able to look. All three callers (LinWinMod, WinTermMod, the read-write "Windows
files" CLI flag) treated any not info.healthy result as a reason to refuse outright, including this permanently
unanswerable case - so even once #1 and #2 above were fixed, the pre-flight check would have still blocked every
single unprivileged attempt, forever.

Fixed: probe() now returns a distinct kind="unreadable" specifically for "couldn't even open the device" (as
opposed to "dirty"/"hibernated"/a genuine "other" read failure, which still correctly block). All three
callers now treat "unreadable" as inconclusive rather than as a refusal, and fall through to the real,
authoritative check: the privileged mount attempt that follows, exactly the way a healthy result already did.

Net result

Confirmed live, end to end, on the real tablet: lintab-windows-files enable --read-write now writes a working
fstab entry, and mount /media/windows succeeds read-write through ntfs-3g. LinWinMod's "Open Windows files"
should now work for the first time on this kernel.

Files: lintabos-core_0.3.16_all.deb + .minisig, SHA256SUMS.