This got cross-posted to electronics.stackexchange. The short answer is that it's not possible to detect all of this kind of hostile hardware attack in software.
If you had a probing device on the bus that actively requested memory reads, it would be possible to detect it by observing delays in memory reads. You'd have to specifically go looking for it by setting up an uncached read with timing measurements before and after, but you could detect it.
However, if I were building this sort of attack system I'd simply have a shadow dual port RAM connected to the same write lines, storing a copy of all memory access since bootup. I could then read from the copy without disrupting timing of the main memory access. It's not trivial to build such a thing - it requires careful attention to avoid disrupting the electrical signals to the RAM - but it's quite feasible against socketed or soldered DRAM. It's not feasible against internal RAM of a SoC, or stacked chip RAM such as in the Raspberry Pi.
(This is not to be confused with "cache snooping", which is a normal part of a multiprocessor system)
Edit in response to comment: it's not especially different on a multiprocessor system; on a NUMA system you need one snooping probe per memory bus. It's certainly something that requires a lot of effort and physical access, so it's mostly used for breaking into devices that you own such as games consoles and mobile phones. It's not something I'd expect to see in a datacenter; high-value target machines are likely to be locked away in tamper-alarmed cases to defend against this kind of thing.
(References? Does this SE have a Wikipedia-style ban on original research?)