Visual glitch remaining on screen with weirdly encoded accentuated characters

- [x] I have read through the manual page (`man fzf`)
- [x] I have the latest version of fzf
- [x] I have searched through the existing issues

## Info

- OS
- [x] Linux : archlinux up-to-date
- [ ] Mac OS X
- [ ] Windows
- [ ] Etc.
- Shell
- [ ] bash
- [x] zsh
- [ ] fish

```
fzf --version
0.21.1
zsh --version
zsh 5.8 (x86_64-pc-linux-gnu)
```

## Problem / Steps to reproduce

I create a test folder with :
- a lot of dummy files (just to be able to scroll in fzf)
- some files with regular accentuated characters (é, à, ç, ...) <-- no issues with them
- some files with "weirdly encoded characters" : they are displayed most of the time as regular encoded characters (in a "ls" command for example), but are in fact coded on two characters : the letter + the accent (like "a" + "`"), and shown like "e<0300>a<0300>" in some situations (like when moving them through "mv"))

Test situation (no issues here) :

After launching fzf in that folder (without any options), and using page-up / page down, the accents (just the "`" characters) are then constantly displayed on the screens and never deleted ! (see screenshot), and even when navigating again with page-up/down.
So it's a visual glitch in the display of that kind of characters.
I have no idea how to enter these characters from scratch, but i had several files with that kind of characters.

Here note the weird accents remaining on the screen (the more files with that pattern, the more glitches over time) :

To be noted : i'm running an environment with UTF-8 ("LANG=fr_FR.UTF-8")

Test folder saved in that git repo : https://github.com/SR-G/fzf-weird-visual-glitches (tested on another remote server and i'm to reproduce the issue on that second server)

Problem is probably about some erasing logic inside `fzf`, as these accentuated characters are in fact displayed as two characters (this is also visible when selecting them in order to copy'n'paste them).

About tested terminals :
- Windows 10 with `cmd.exe` + `ssh @` (through the OpenSSH implementation now provided through windows) : problem reproduced
- Windows 10 with `wsl.exe` + debian + regular ssh command : problem reproduced
- Windows 10 with `wsl.exe` + debian + fzf (without SSH) : problem reproduced (so no need to SSH on a remote host and to use a terminal emulator in the end)
- Netsarang XShell : problem reproduced
- PuTTY : problem NOT reproduced