This is closer to what I was thinking. But it's hard to be sure what that result is telling us, since it is erroring before it completes the list. Can you try it with lsf instead of ls, in case duplicate directories are part of the problem? There was a very similar issue here not too long ago:
One other thing you could try is running your sync again with --disable ListR
I say that because it looks like the specific error you are encountering only happens in a ListR codepath:
--disable ListR should make it fall back to List instead (which may still fail, but probably in a different way that could give us more clues)
Well, the rclone test info --check-base32768 suggested above is where I would have started, but it looks like you already tried that and it didn't show a problem. So this may not be it. At the same time, I also see that the docs state that Jottacloud is case insensitive. I'd have assumed that base32768 would not be a good choice for a case-insensitive backend. One possible explanation is that the case insensitivity only presents a problem in the rare event of a collision. i.e. often an insensitive remote can handle hello and HELLO -- but just not both at the same time. As long as you have only one or the other, you might not notice a problem. The problem arises from treating those as interchangeable, when they are not for base32768 purposes.
One more observation about my (Conflict ) theory: the relevant log line is saying illegal base32768 data at input byte 52. And it just so happens that 㿄䈸㤦槚蝄⡘䘺欹嶃▸萰固ߊ哙ᣓ䥼禰痰㯔䅀㛞晪㯔伔闕ꂟ is exactly 52 UTF-16 bytes.
Likewise, it decodes as valid base32768, but as soon as you add a space, it chokes with illegal base32768 data at input byte 52.
(click "Run")