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.