fix: load allocation bitmaps on open and add test function

[JingMox]

Description
Filesystem::open only called ext2fs_open, which reads the superblock and group descriptors but leaves fs->inode_map and fs->block_map NULL. Any allocation on a reopened handle (mkdir, mkdir_p, write_file, symlink, alloc_inode, alloc_block) therefore failed with EXT2_ET_NO_INODE_BITMAP, breaking guest-binary injection into existing images during base-image creation.

Filesystem::open now calls ext2fs_read_bitmaps immediately after opening. The call is idempotent and installs the write_bitmaps callback, so dirty bitmaps are flushed back to disk on close. Handles returned by open now support the same operations as handles returned by create.

This also adds regression coverage for the bitmap round-trip and for the nested-inject paths, and serializes the image-building tests to eliminate an intermittent parallel-test failure caused by libext2fs's macOS mount check (libc getmntinfo() is not thread-safe).

Verified: cargo test -p bux-e2fs passes 9 tests + 5 doctests across repeated parallel runs; cargo clippy --workspace --all-targets --all-features -- -D warnings and cargo fmt --check are clean on the pinned stable toolchain.

Changes
crates/bux-e2fs/src/ext4.rs
Filesystem::open loads the allocation bitmaps after ext2fs_open. The RAII wrapper is constructed first, so a failed bitmap read still runs ext2fs_close; libext2fs frees any partially read map itself.
Updated alloc_inode/alloc_block docs: bitmaps are now guaranteed after both create and open.
crates/bux-e2fs/src/sys.rs
Hand-written ext2fs_read_bitmaps extern, kept out of the bindgen allowlist so it works without the regenerate feature (adding it there would collide with the declaration, E0428).
crates/bux-e2fs/build.rs
Comment documenting why ext2fs_read_bitmaps and ext2fs_default_journal_size are intentionally absent from the allowlist.
crates/bux-e2fs/Cargo.toml
Added tempfile as a dev-dependency for the image tests.
Tests (mod tests in ext4.rs)
reopened_image_supports_allocation: create → close → reopen → allocate → reopen again; asserts the directory survives the round-trip and that a fresh inode skips the ones allocated earlier, proving the dirty bitmaps were written back on close rather than only held in memory.
inject_file_creates_missing_parent_directories, inject_file_is_idempotent_when_parents_exist, inject_file_without_parent_directory_works: nested-inject coverage requested in #54.
FS_TEST_LOCK serializes the image-building tests: the journal's mount check goes through libc getmntinfo() on macOS, whose process-global buffer is not thread-safe, so parallel builds failed intermittently with Errno(EFAULT/EPERM). If production ever builds base images concurrently, this serialization should move into Filesystem::add_journal.
Fixes #57