I don't recall the exact client version, it was at least several months before they dropped v1. Maybe even longer. It was just a simple walk of the .text section that looked for a hard-coded set of changes (I think mainly some of the earlier maphacks, etc). I noticed it when I set an on-access hardware breakpoint on some of the game's code, and it tripped. That was why I wrote some of my earliest maphack releases using hardware breakpoints and a vectored exception handler, so it would avoid it. (They later detected that maphack by looking for the hashed DLL name. )
It's always interesting to see someone else's approach to the problem. It seems like a lot of what you did was based around static analysis of the game, whereas my approach was generally more on the dynamic analysis side. I figured out how the anti-cheat(s) worked by using a custom user-mode syscall hook that watched some of the more interesting calls into ntdll. I was able to find all the relevant anti-cheat code from there. The disadvantage there is I could miss code that didn't execute, but the advantage is I wouldn't have to put much effort into searching for new code in a big patch.
The way they were searching for Exile Buddy was watching for an open handle and then opening the executable file on disk to try to search for a signature. They did the same thing for PoeHUD too, though I think that one was easier because the PE header of PoeHUD has the PDB name in it. I don't know whether Buddy did or not.