Document the 0.4.0 surface

The front page, the crate page, and the guide all described a crate with one
filesystem in it. They now describe the one that ships: two filesystems, each a
feature a build takes or leaves, reached through a root that belongs to neither.

The guide's formatting and command-line pages carry FAT beside ext rather than
after it, since a reader arrives wanting one of them and should not have to read
the other first. The changelog states what 0.4.0 adds, what moved to the root
and what that means for a caller who named it under `ext`, and the defects fixed
since.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: gregordinary

CHANGELOG.md

@@ -1,14 +1,15 @@
 # ferrosys
 
-A pure-Rust ext2/ext3/ext4 filesystem: it builds and reads filesystem images in
-userspace, over ordinary byte streams, in safe Rust.
+Pure-Rust filesystem tooling: it builds and reads filesystem images in userspace, over
+ordinary byte streams, in safe Rust. Two families — ext2/ext3/ext4 and FAT12/FAT16/FAT32 —
+and a build takes the ones it names.
 
 This Cargo workspace holds two crates:
 
-- [`ferrosys`](crates/ferrosys) — the library: a formatter and reader with resize-safe,
-  byte-reproducible on-disk geometry.
+- [`ferrosys`](crates/ferrosys) — the library: a formatter and reader per family, each
+  behind a feature of its own, with byte-reproducible on-disk geometry.
 - [`ferrosys-cli`](crates/ferrosys-cli) — the `ferrosys` binary, which puts the library
-  on the command line.
+  on the command line and carries every family.
 
 Both build on Rust 1.88 or newer.
 
@@ -18,25 +19,31 @@ Both build on Rust 1.88 or newer.
 
 ## Highlights
 
-- **ext2, ext3, and ext4** — one formatter and one reader across the lineage, from the
-  classic direct/indirect block map to extent trees of any depth.
-- **Resize-safe geometry** — descriptor backups and reserved GDT blocks, sized by a grow
-  reservation, let the image grow in place without relocating its descriptor table.
-- **Byte-reproducible** — the UUID, hash seed, and timestamps are inputs, so the same
-  inputs write the same image every time.
-- **Full fidelity** — every file type, ownership and mode bits, nanosecond timestamps,
-  extended attributes, POSIX ACLs, metadata checksums, a jbd2 journal, and an orphan file.
-- **A robust reader** — bounds-checks every field into typed errors, reads foreign images
-  other tools wrote, and scans a whole image into typed anomalies rendered as JSON, SARIF,
-  or a table, allocating in proportion to the bytes an image holds rather than to what it
-  claims.
+- **Two families, one at a time or both** — ext2, ext3, and ext4 across one lineage, from
+  the classic direct/indirect block map to extent trees of any depth; FAT12, FAT16, and
+  FAT32 across another, where the type is derived from the cluster count rather than
+  chosen. Each is a feature, so a consumer wanting one filesystem compiles one.
+- **Resize-safe ext geometry** — descriptor backups and reserved GDT blocks, sized by a
+  grow reservation, let the image grow in place without relocating its descriptor table.
+- **Byte-reproducible** — the identifiers and timestamps an image carries are inputs, so
+  the same inputs write the same image every time and nothing about the machine that wrote
+  one reaches it.
+- **Full fidelity, and a report where a format cannot hold it** — ext records every file
+  type, ownership and mode bits, nanosecond timestamps, extended attributes, POSIX ACLs,
+  metadata checksums, a jbd2 journal, and an orphan file. Where a format holds less than
+  the tree it is given, what it could not keep is named rather than dropped in silence.
+- **A robust reader per family** — bounds-checks every field into typed errors, reads
+  foreign images other tools wrote, and scans a whole image into typed findings rendered as
+  JSON, SARIF, or a table, allocating in proportion to the bytes an image holds rather than
+  to what it claims.
 - **Built for scale** — streaming in both directions: a format writes only the blocks the
   filesystem uses, so an image stays sparse and may be larger than memory, and a read
   windows its way through a file rather than holding it, so pulling a multi-gigabyte file
-  out of an image costs a working set. 64-bit block addressing reaches past 16 TiB.
-- **Sources** — a programmatic tree, a tar archive, or a directory on this machine, each
-  handing a file's bytes over as a handle so a format's peak memory is the largest single
-  file rather than the sum of them all.
+  out of an image costs a working set. ext's 64-bit block addressing reaches past 16 TiB.
+- **Sources and sinks, belonging to no family** — a programmatic tree, a tar archive, or a
+  directory on this machine feeds whichever family is being written, and an archive or a
+  directory drains whichever one was opened. Each hands a file's bytes over as a handle, so
+  a format's peak memory is the largest single file rather than the sum of them all.
 
 The [crate README](crates/ferrosys/README.md) and the
 [guide](https://gregordinary.github.io/ferrosys/) carry the complete feature list.
@@ -50,14 +57,18 @@ $ ferrosys format --size 512M --uuid "$(uuidgen)" --time 1700000000 \
       --from-tar rootfs.tar rootfs.img
 $ ferrosys inspect rootfs.img
 $ ferrosys extract rootfs.img --to-tar - | tar -tv
+
+$ ferrosys format --type fat32 --size auto --from-dir seed/ seed.img
 ```
 
-`format` writes a filesystem — from a tar archive, a directory tree, or empty, at a size
-you name or one `--size auto` finds from the contents — `inspect` reports on one and says
-whether it is sound, `extract` reads the contents back out as a tar archive, a directory
-tree, one file's bytes, one path's metadata, or a listing, `detect` says which filesystem
-an image holds, and `identity` changes what one is known by. The identifiers and timestamps are inputs, so the same inputs
-write the same image every time. The exit codes mirror `e2fsck`'s. See the guide's
+`format` writes a filesystem — of the type `--type` names, from a tar archive, a directory
+tree, or empty, at a size you name or one `--size auto` finds from the contents —
+`inspect` reports on one and says whether it is sound, `extract` reads the contents back
+out as a tar archive, a directory tree, one file's bytes, one path's metadata, or a
+listing, `detect` says which filesystem an image holds, and `identity` changes what one is
+known by. Every command takes any family the binary carries. The identifiers and
+timestamps are inputs, so the same inputs write the same image every time. The exit codes
+mirror `e2fsck`'s. See the guide's
 [command-line chapter](https://gregordinary.github.io/ferrosys/cli.html).
 
 ## Build and test
@@ -66,6 +77,7 @@ write the same image every time. The exit codes mirror `e2fsck`'s. See the guide
 cargo build
 cargo test
 cargo doc --no-deps            # clean under RUSTDOCFLAGS="-D warnings"
+ci/lint-features.sh            # and clean in every feature configuration on offer
 ```
 
 ## Documentation