test(fuse): delete files as they upload in the simulation runs

The runs did not find B105 with its fix reverted. Drive lists a trash
later than the round trips take, so the drain never saw its own
client's delete while it still held the write.

The FakeDrive can now hold the next read of one node on its way to
Drive. A new profile, one-client-deletes, writes a file Drive holds,
waits for the drain to read the node back, deletes the file, and lets
the read go on once Drive shows the trash. A conflict the drain keeps
because a client's own file was trashed now fails the run as a false
conflict. With B105's fix reverted, seeds 1 and 2 fail on it.

Outside the step, such a conflict is counted as B134 when the copy is
named after the file: the drain looked after an online unlink had
trashed the file on Drive but before it dropped the write. Seed 3 of
three-clients came up with it once.

Half the time the step makes the file again before the read goes on.
That is B133: the new file's write takes the op id the delete freed,
and B105's check finds it. The runs count it.

The runs also count B132, an ENOENT after a restart that restored
queued ops, in a seed that lost the link. Seed 4 of one-client-flaky
failed on it. The known-bug matchers now also see what was logged
before the call.

crates/pdfs-fuse/src/sim/model.rs

@@ -224,7 +224,7 @@ impl Model {
         self.tree.keys().any(|other| is_below(other, path))
     }
 
-    fn files(&self) -> Vec<&String> {
+    pub(crate) fn files(&self) -> Vec<&String> {
         self.tree
             .iter()
             .filter(|(_, entry)| entry.is_some())
@@ -318,7 +318,7 @@ impl Model {
 }
 
 /// Content for a write: short and recognisable, now and then empty.
-fn data(rng: &mut Rng) -> Vec<u8> {
+pub(crate) fn data(rng: &mut Rng) -> Vec<u8> {
     let len = if rng.chance(0.1) {
         0
     } else {