Your IAP is almost certainly not marked as a full rogue, because there has been no wired side confirmation of the MAC. So yes, I think you're right.
BEWARE of course, if you change your test rig, if the IAP discovers the controller it will convert!!!
In the past, I always used something more dirty for these test processes. Cisco autonomous AP, Netgear or something like that.
Here's the main rule on the wire. Yes, one of the APs or AMs controlled by the detecting controller must "hear" the MAC of the rogue AP on the wired port. And further, what the system REALLY wants to see, is a MAC of a wireless client in the air on the rogue, and on the wire (on a "internal" VLAN) searching (ARPing) for a desitnation of an IP default gateway the same as the controlled AP knows about (by listening). The controller can't do this. In general deployments to achieve this, I put 1 or 2 dedicated AMs onto VLAN trunk/tagged links at core or distribution customer switches. This way, those AMs are able to classify the rogue properly for the solution.
Oh, by the way, look out for VRRP and HSRP considerations for this. There are options you can configure to tell the system to assume VRRPs and HSRPs are "interesting" (i.e are to be considered local VLAN gateway macs). Something like this might be needed (for hsrp)...
ids unauthorized-device-profile "default"
allow-well-known-mac hsrp
It would be dangerous for the system to do this by default, as it may trigger false positives where your legitimate "neighbour" was also using hsrp on their LAN.
Hope this helps?