Snapshot of every byte/value an HFS+ mutation can touch — taken at the
start of each EditableFilesystem method so a mid-flight failure can
rewind to byte-identical pre-call state instead of leaving the catalog
half-applied.
Variant of create_blank_hfsplus that lets the caller request minimum
catalog and extents-overflow B-tree sizes (in bytes) — e.g. a clone target
that must hold every record from a fragmented source, or a test that needs a
deep catalog without a multi-GiB volume. Each minimum is rounded up to whole
nodes and raised to the 4-node floor; the catalog also never drops below the
volume-scaled default_hfsplus_catalog_bytes.
Volume-scaled default catalog B-tree size, in bytes, for a fresh HFS+
volume. Mirrors classic HFS’s default_btree_sizes: ~0.5% of the volume so
a blank holds thousands of records before exhausting its node budget (HFS+
has no grow-on-full path — docs/hfsplus_btree_growth_plan.md §4c). The
build_blank_hfsplus_front caller clamps the result to whole nodes in
[4, header-bitmap capacity].
Mirror the volume header 1024 bytes before the partition end when the
volume is smaller than its partition, where Mac OS looks for it (R-057).
Returns whether a copy was written.
Streaming variant of create_blank_hfsplus. Writes the metadata
regions (boot, VH, bitmap, B-trees, alt-VH) into target at at_offset
and leaves the free middle untouched. Caller is responsible for sizing
the underlying file (e.g. via File::set_len) so reads of the free area
return zeros.