Reusing filenames can cause files to become unintentionally shared

### Describe the bug
If you share a file, that share key can be used to access to any future file with the same filename.

### To Reproduce
1. Upload a file with a particular filename
2. Create a share for the file
3. Delete the file
4. Upload a different file (i.e. different contents) with the same filename
5. Dereference the share link

### Expected behavior
The share link 404s, and listing the share key results in 0 files.

### Server details (if you're NOT using docker/podman)
* **server OS / version:** Debian bookworm
* **what copyparty did you grab:** sfx
* **how you're running it:** init
* run copyparty with `--version` and grab the last 3 lines (they start with `copyparty`, `CPython`, `sqlite`) and paste them below this line:
copyparty v1.19.15 "usernames" (2025-09-29)
CPython v3.11.2 on Linux64 6.1.140 [GCC 12.2.0]
sqlite 3.40.1*1 | jinja 2.11.3 | pyftpd 1.5.10 | tftp 0.4.0
* **copyparty arguments and/or config-file:** `-e2ds -e2ts --shr /shared` (not complete)

A issue envolve a reutilização de share keys quando os nomes de arquivo são reutilizados. Examine a lógica de compartilhamento de arquivos, provavelmente no código que trata de uploads, exclusões e criação de shares. Comece encontrando onde as share keys são geradas e associadas aos arquivos. Verifique se a associação é baseada apenas no nome do arquivo. As etapas de teste fornecem um caminho claro para reproduzir o problema; implemente uma correção para invalidar as share keys ou impedir que sejam reutilizadas após a exclusão de um arquivo. Verifique executando as etapas de reprodução.

Escrita pelo modelo de indexação a partir do texto da issue.