Data is encoded via bencode so it's a byte wise format. Known malicious trackers usually inject stuff in the sense that e.g. there is a payload to all known PDF files appended with a payload that targets the clients' OS.
The announcement related APIs are fairly easy to implement, but I wouldn't bet on it being implemented in a fuzzed testing environment. Transmission, for example, had multiple vulnerabilities over the years. Not sure about the other client implementations.
That's correct. Most clients revalidate stuff after the download has been completed. Depending on how well they can redownload chunks (e.g. web seeds sometimes don't allow that if the web server does not support 206 Partial Content headers) you might have to redownload the file completely afterwards.
I had different experiences with different clients, so I guess it's work in progress on what a client does when the cache was poisoned.
Hashing algos are mostly SHA based ones that are used. No idea if someone managed to inject stuff and found collisions for SHA1 yet though. I know that there has been PoCs in the past for hash collisions of PDF files.
The announcement related APIs are fairly easy to implement, but I wouldn't bet on it being implemented in a fuzzed testing environment. Transmission, for example, had multiple vulnerabilities over the years. Not sure about the other client implementations.