fix(fuse): land a move right after a rename, and rename across folders quickly (B121)

The SDK caches each node, including the name hash it sends with the next
rename or move, and only an event evicts it. Renames and moves didn't
update that copy. So after a rename, the next change to the same node
went out with the old name hash, Drive refused it as out of date (422),
and the retry kept sending the stale hash until the event feed came
round, up to 10 seconds later.

- Every remote rename and move goes through `Core::rename_remote` or
  `Core::move_remote`. Both drop the SDK's copy of the node after a
  successful change and before each out-of-date retry, so the retry
  sends the current hash.
- A plain move was not retried at all, so a move right after a rename
  failed with EIO through the mount and with "out of date" from
  `pdfs move`. It now retries like a rename.
- The drain's combined move-and-rename also drops the SDK's copy once
  it lands.
- A rename that also changes folders through the mount replies only
  once both halves have landed. When the move fails, the file keeps
  its new name in the source folder, the tree is told so, and the
  rename reports EIO. A dropped link still queues the change.

B111's cause in docs/BUGS.md is corrected to the same SDK cache. The
acceptance case "regression B121" renames and moves a file at once
through the mount and through `pdfs`, and checks names and bytes.

docs/TESTING.md

@@ -241,6 +241,12 @@ eight times through the mount. On a mount it also does so three times with
 `pdfs rename`, after the queue is empty, so the renames race nothing but Drive.
 It runs against the reference too.
 
+**B121** (a file renamed and moved at once lands) renames a file, moves it into
+a subfolder and renames it back across folders through the mount, with no pause
+between the steps. On a mount it then runs `pdfs rename` and `pdfs move` back to
+back. The file must end up where it was sent, with its bytes, and the case
+reports how long each half took. It runs against the reference too.
+
 **B98** (an upload superseded by a write ends) writes 64 MiB and waits for its
 upload to show in `pdfs transfers`, then appends to the file. The queue must
 drain, the old upload must leave the transfer list, and the file must hold
@@ -331,8 +337,8 @@ bug is open at the moment. B114 to B117 started as such cases.
 A full account run with `--journal-check` checks these `docs/BUGS.md` entries,
 many of them fixed but not yet verified:
 
-- B48, B80, B94, B95, B98, B100, B101, B102, B111, B114, B115, B116, B117 and
-  B119, each with its own `regression B<n>` case.
+- B48, B80, B94, B95, B98, B100, B101, B102, B111, B114, B115, B116, B117, B119
+  and B121, each with its own `regression B<n>` case.
 - B118, with "application workloads" and "block boundaries", which failed on
   it. It needs Drive to be slow to list a new node, so a clean run is weak
   evidence.