Expanded fuzz testing a bit, found/fixed an mid neighbor update bug

This bug was just overlooked in testing the mtree, fortunately dir
fuzzing found it. Though since this depends on neighboring mdirs, it
probably would have been found quicker with smaller block sizes. At the
moment I am only testing on NOR-liked geometry (4KiB blocks).

The fix is easy, we can use the difference in the mtree size to
determine if a split or drop happened in mdir commit, since at most one
of these can happen on any mdir commit.

Also added an explicit test for mid updates when splitting and dropping.

tests/t4_alloc.toml

@@ -142,7 +142,7 @@ code = '''
     // test that all of our metadata entries are still there
     lfs_size_t i = 0;
     for (lfs_ssize_t mid = (lfsr_mtree_isinlined(&lfs) ? -1 : 0);
-            mid < lfsr_mtree_weight(&lfs);
+            mid < (lfs_ssize_t)lfsr_mtree_weight(&lfs);
             mid++) {
         lfsr_mdir_t mdir;
         lfsr_mtree_lookup(&lfs, mid, &mdir) => 0;