btrfs tools: do not compare against the booted profile on another filesystem

[Yury-MonZon]

Six commits, one concern: under -d/--device the tools operate on a filesystem we did not boot
from, and in six different places they consulted the running root for a fact that belongs to the
target. A recovery boot is the only environment where those two diverge enough to notice, which is
why none of this surfaced earlier.

Subvolume ids. Five tools compared ids, or names, with the booted profile's. The two
filesystems hand out 256, 257 and so on, so a collision is a matter of time. Demonstrated by
creating profiles on a loop filesystem until one landed on the booted profile's id 265, at which
point delete-profile -d refused to delete it, reporting it as the profile you are booted into.
top_is_booted_fs() now answers the question once, by comparing filesystem UUIDs.

The entries directory. flipper-bls.sh defaults to the absolute /boot/loader/entries, right
on a booted system and wrong under -d. In recovery /boot is an empty directory on the RAM
rootfs, so a profile created there got its entry written to RAM and was left unbootable after the
next reboot, while a profile deleted there kept its real entry on disk. The three tools that mount
the top level now state where the entries live; the lib default is untouched for the
kernel-install hooks.

The menu band. profile_base_nn reads the profile list, which lives inside a profile rather
than in the running system's /etc. Recovery has none, so every name resolved to an empty band and
the token silently lost its sort prefix: flipperos-Desktop where the build wrote
900-flipperos-Desktop, which also reorders the menu, since a leading letter sorts above a digit.

The sort key. os_sort_key read the running /etc/os-release, so an entry written from
recovery described the recovery system. It now reads the target's, which reproduces what the build
writes for every entry.

The filesystem UUID. create-profile rewrites a profile's fstab, and flipper-bls rewrites the
cmdline's root=UUID, so a root built elsewhere still boots here. Both read current_fsuuid(),
which answers for the booted root, so both silently did nothing under -d. Landing the 775 build's
packs on a 777 filesystem from recovery showed the cost: the restored profile kept the build
machine's UUID in all five fstab entries, and its entry had no root= at all.

The base cmdline. compute_base_opts read $CONF_ROOT/cmdline from the running root, absent in
recovery, so BASE_OPTS came out empty: no root=, no audit=0, no console policy. It now prefers
the target's own copy, with KERNEL_INSTALL_CONF_ROOT still winning for the hooks.

Plus one usability fix in the same area: a piped golden base is now routed like a file. The
destination was chosen by peeking the subvolume name out of the stream, which only worked for a
file, so a _stock arriving over ssh (the form this tool's own examples show) was filed as an
ordinary restore point, where migrate-profile never looks for an ancestor. Buffering the head of
stdin makes the name readable and the buffer is replayed ahead of the rest. Relocating afterwards is
not possible: a received subvolume is read-only, mv refuses, and clearing ro to force it drops
received_uuid, which is what btrfs matches a later incremental's parent on.

Testing

All on hardware, in a recovery boot, since that is the only place these paths differ: 97 checks
across four suites, plus a dedicated run that lands the real 775 build's packs on a 777 filesystem
and checks the restored profile end to end. After the fixes that run reports the stream routed to
@stock-snapshots, the incremental following its parent, the fstab rewritten across every entry,
and an entry reading root=UUID=<this filesystem> audit=0 console=tty1 ... rootflags=subvol=@Desktop-775.

Also covered here for the first time: create-profile -m/--move, proven to preserve parent_uuid
with a control showing a plain copy re-parents instead, and the full send-out, receive-back, promote
cycle.