LintabOS 0.3.13

LintabOS 0.3.13 (pre-release)

The real bug behind "Describe current boot entry" reporting no Windows boot manager at all, found and fixed the
same day as 0.3.12, by testing live against a real Duet 3.

What was found

On any real, already-installed LintabOS system, the EFI System Partition is always already mounted at
/boot/efi - LintabOS's own GRUB lives there too, on the same shared ESP as Windows. disks.esp_has_windows()
and disks.esp_free_bytes() always tried to mount the ESP fresh at a new temporary path regardless, which the
kernel refuses outright for an already-mounted device whose read-only/read-write state would change ("Can't
mount, would change RO state"). The result: both functions silently reported "no Windows boot manager here" /
"0 bytes free" on every real installed system - not because anything was wrong with the ESP, but because the
mount attempt itself was doomed from the start. This is shared, pre-existing code (installer/lintab/disks.py),
also used by the dual-boot partitioner and Remove LintabOS - on a real install, Remove LintabOS's own
esp_has_windows safety check would have hit the same failure (refusing to run, not doing anything unsafe, but
refusing for the wrong reason).

Fixed with a new disks.mount_point_of() helper: both functions, and lintab.bcdbackup's own ESP mounting, now
check /proc/mounts for an existing mount first and reuse it as-is - never mounting (or unmounting) something
the rest of the system still needs.

What this unblocks

With both this and 0.3.12's battery-detection fix in place, "Describe current boot entry" now actually works
on a real installed system. First real result, from the same Duet 3: recoverysequence is present and points at
a real GUID - recovery does look properly configured - and, as expected, onetimeadvancedoptions isn't set yet,
since neither previous write attempt ever actually reached the BCD (both were blocked by the two bugs above, not
by anything wrong with the write itself or the underlying mechanism). The path is now actually clear to test the
write for real.

Also fixed in passing: describe_default_entry was mislabeling one element ("23000003") with a friendly name
that's only correct when it belongs to {bootmgr} itself - the real OS loader entry this function actually
inspects carries its own, different, not-yet-identified element under the same numeric ID. Removed the
mislabel rather than show a confident wrong name.

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