rbyd: Allow refetching after claiming erased-state

Except for niche file snapshotting, most btree updates until this point
are probably linear, i.e. a successful commit replaces any internal
rbyd state that has been claimed. In this model it makes sense to mark
claimed rbyd as "invalid", since failure to replace the claimed state
indicates something went wrong during the commit.

But this isn't necessarily true when snapshotting, since we don't
replace the state of claimed snapshots.

But wait, shouldn't snapshotted rbyds become readonly? Not necessarily!
Rbyds can have multiple trunks with unrelated (or in this case, shared)
histories, so there's nothing wrong with refetching an rbyd and
continuing to commit after another snapshot commits to tbe block.

Eventually both snapshots will need to compact and diverge into two
blocks, but until then sharing an rbyd makes the most of available
erased state.

At least in theory, experience will show us how well this works.

---

Also note this is not true for mdirs. We view mdirs as atomic and always
up-to-date, so snapshotting doesn't really make sense.

lfs3.c

@@ -2750,7 +2750,8 @@ static void lfs3_rbyd_init(lfs3_rbyd_t *rbyd, lfs3_block_t block) {
 
 #ifndef LFS3_RDONLY
 static inline void lfs3_rbyd_claim(lfs3_rbyd_t *rbyd) {
-    rbyd->eoff = -1;
+    // mark as needing fetch
+    rbyd->eoff = 0;
 }
 #endif
 
@@ -7990,7 +7991,10 @@ static inline uint32_t lfs3_rev_inc(lfs3_t *lfs3, uint32_t rev) {
 // mdir convenience functions
 #ifndef LFS3_RDONLY
 static inline void lfs3_mdir_claim(lfs3_mdir_t *mdir) {
-    lfs3_rbyd_claim(&mdir->r);
+    // mark erased state as invalid, we only fallback on this if a
+    // commit fails, and at that point it's unlikely we'll be able to
+    // reuse the block
+    mdir->r.eoff = -1;
 }
 #endif