0.4.0: a machine can run kuma, and its disks are built on ext4

Two changes since 0.3.0 alter what a build produces rather than what the
tool offers, which is what the minor is for on 0.x.

Every image now ships /usr/bin/kuma (920f5e6). Machines installed from a
0.3.0 image have the baked declaration, the convergence units, and the
helpers, but nothing to run them, so `kuma update --yes` on an
ISO-installed machine was a documented promise with no binary behind it.
An image built by this version carries the kuma that built it.

Disks are built on ext4 rather than xfs (5914e87). A disk from 0.4.0 is
a different filesystem than a disk from 0.3.0, which matters to anyone
who has one already; nothing migrates and nothing needs to, since a VM
disk is disposable and `--rebuild` makes the new one.

The examples also lost three flatpaks (e1c6238). A rebuild picks that up
as a removal, because convergence takes back what it installed.

Cargo.lock carries the workspace member's own version, so it moves in
the same commit or every --locked call in CI disagrees with it.

Author: Letdown2491

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "kuma"
-version = "0.3.0"
+version = "0.4.0"
 edition = "2021"
 # Set by sha-crypt 0.6, the highest floor anything here asks for. Without
 # it, an older toolchain fails somewhere inside a dependency instead of