HFS+ B-tree fork grow-on-full (§4b A/B/C) + classic-HFS fsck_hfs fix

[danifunker]

Implements the deferred §4b of docs/hfsplus_btree_growth_plan.md (HFS+ B-tree fork grow-on-full), and — because validating it against a real Mac surfaced them — fixes several latent on-disk-format bugs that only an HFS-capable Mac could catch. All acceptance testing was done against real fsck_hfs: modern macOS for HFS+/HFSX, and a Mac OS X 10.4 (Tiger) box for classic HFS.

Commit 1 — feat(hfsplus): §4b grow-on-full (A/B/C)

The catalog / extents-overflow / attributes B-trees now grow their backing fork on demand (grow_btree_fork) instead of returning DiskFull, so an under-sized or foreign catalog fills in place.

• Phase A — contiguous tail growth (keeps the fork at one extent).
• Phase B — spills the 9th+ extent into the extents-overflow B-tree, persisted by a new overflow-aware write_fork_data_with_overflow (the write-side mirror of read_fork_with_overflow).
• Phase C — appends map nodes past the (node_size-256)*8 ≈ 30,720-node header-bitmap cap.
• Phase 0 — rb-cli new --fs hfsplus [--case-sensitive] [--min-catalog BYTES] (GUI/CLI parity + drives the macOS recipe).

Two foundational blank-builder bugs fixed along the way (affected every HFS+ image we build from scratch — blanks and the defrag/clone path used by restore + HFS-expand):

• Invalid BTH length — the B-tree header wrote BTHeaderRec as 128 bytes; Apple requires exactly 106 (record 1 at 120, node bitmap at 248). This also resolves the header-vs-map-node capacity discrepancy.
• Empty-tree representation — an empty tree was depth-1 with an empty root leaf (Apple uses depth-0 / no leaf), and the bitmap didn't reserve the trailing alternate-VH block. btree_insert_full now bootstraps the root leaf on the first insert into a depth-0 tree, and returns a clean DiskFull (pre-split free_nodes >= depth+1 check) so the grow-retry can't half-apply a split and duplicate a record.

Commit 2 — fix(hfs): classic-HFS filStBlk/filRStBlk must be zero

build_file_record (and write_resource_fork) wrote the fork's first allocation block into filStBlk (offset 24) / filRStBlk (offset 34). Those are the File Manager's in-memory cache and must be 0 on disk — the real location is the extent record at offset 74/86. A non-zero value makes fsck_hfs report "Reserved fields in the catalog record have incorrect data" (E_CatalogFlagsNotZero). Pre-existing; real Mac OS ignored the on-disk value so files worked, and our own fsck never checked it. The reader uses the extent record, so zeroing is safe. Covers HFV too.

Validation

• HFS+ grow A/B/C + defrag-clone output: fsck_hfs -f -n "appears to be OK" and mountable on macOS.
• Classic HFS: confirmed on real Tiger 10.4.12 — fresh multi-file image is fsck_hfs-clean and mounts with all files intact (diffed catalog records against a Tiger-created reference to pin the root cause).
• New tests: Phase A/B/C grow tests, the empty-tree/header fixes, and test_hfs_file_record_first_alloc_block_fields_are_zero. cargo test --lib green (2140), build --all-targets zero warnings, clippy -D warnings clean.

🤖 Generated with Claude Code