Removals not synced

[max-privatevoid]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

ali touch test/x.txt
bob sync ali
# bob now has the file
bob info test/x.txt
# bob removes the file
bob rm test/x.txt
# sync the removal
ali sync bob
ali ls -R
# ali should not have test/x.txt anymore

Please always include the output of the following commands in your report!

• brig bug -s
  go version: go version go1.17.11 linux/amd64
  uname -s -v -m: Linux #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980 x86_64

brig client version: v0.5.3-HEAD+6b7eccf [build: 2022-07-14T17:33:58+02:00]
brig server version: v0.5.3-HEAD+6b7eccf+6b7eccf8fcbd907fc759f8ca8aa814df8499e2ed
IPFS Version: 0.13.0+

Expected behavior
After running the repro steps, test/x.txt should be gone from ali's repo.

Additional context
The repro unfortunately fails to recreate this, but I ran into a much more problematic version of this bug originally. In the repro, ali can delete the file locally and all is well. The way I originally encountered this bug was that even though a certain folder was (manually) deleted on both sides, triggering a sync from either side would recreate the folder, as if the other side still had it.