fix(core): drop a rename replaced while its failure was being recorded (B158)

B141 drops a rename that fails with a newer one queued behind it. The
worker records the failure and releases its claim in two steps, and a
rename queued between them waited behind the old one, which was kept
with a backoff. Released, the old one was not due and the new one was,
so the new one landed first and the old one then put the first name
back.

Releasing the claim now drops the old rename too when a newer one is
queued, and both checks match the node by local id as well as by uid.

docs/CHANGELOG.md

@@ -44,6 +44,8 @@ by its local id, in the queue, the stored tree and pins alike.
   of itself when the link lost Drive's answer to the first try** (B156).
 - **Writing to a file twice in a row no longer fails with "Input/output error" when the link
   lost Drive's answer to reading back the file's last upload** (B157).
+- **A file renamed twice in a row, while the first name was still taken, keeps the second name**
+  (B158).
 - **A file renamed just as its upload finished keeps its new name.** The mount no longer showed
   the old name, and a second rename no longer failed with "No such file or directory" (B152).
 - **A change that waits for a name to be freed no longer waits seconds after it is.** A rename or