fix(ext4): batch metadata writeback while preserving sync semantics (#2271)

• fix(ext4): batch metadata writeback while preserving sync semantics

Small filesystem operations currently pay the complete journal flush protocol on the foreground path. Introduce bounded metadata publication and background batch commits so independent operations share that cost without weakening fsync, fdatasync, syncfs or block-reuse ordering.

• Centralize metadata access and operation publication across namespace, allocation, extent, xattr and delayed-allocation paths. Keep one running and at most one frozen batch, with bounded credits and a 100 ms deadline.
• Preserve the existing five-flush journal protocol and defer retired block and inode reuse until checkpoint and clean-tail persistence complete.
• Separate journal I/O from completion callbacks, reserve completion capacity before publication, and retain accepted ownership on asynchronous failures.
• Add generation-specific Submitted page-cache completion, finite sync targets, error reporting and worker draining during final unmount.
• Share ext4 state and superblock lifecycle across same-device mounts. Keep metadata readers coherent with the inode cache and prevent reader traffic from starving writers or unnecessarily waking background workers.
• Correct external-xattr hashes and block accounting, directory growth accounting, and fragmented-reclaim credit budgeting.
• Add guest regression coverage and real-image tests for batching, delayed allocation, namespace recovery, fragmented reclaim and cache concurrency.

Validation:

• Kernel build passed; 183 lower-level unit tests passed.
• 76 guest tests and Submitted/accounting self-tests passed.
• 124 namespace write/flush crash points recovered with clean e2fsck results.
• Real-image batching, delayed-allocation failure, fragmented-reclaim and inode-cache concurrency checks passed.
• Five-round 100 x 4 KiB benchmark including both syncfs boundaries reduced median total time from 3.662096 s to 2.717986 s.

Existing orphan-list scanning can still cause long tails under sustained unlink workloads. Global allocator OOM injection was not exercised.