Let's break apart the property description:
An active attacker
So an attacker who can both read and create packets on the network
who pretends to be the initiator
In the NK1 handshake, the initiator is anonymous, so it's not really pretending to be the initiator, it is an anonymous initiator like any other NK1 initiator
and records a single protocol run
This just means they remember every message sent and received. You need to do this to analyze the packets later! I'll give the analysis you do below.
can then check candidates for the responder's public key.
You explicitly ask about this part in your question. The responder's public key, whose identity you're trying to hide, is never transmitted in this protocol, so you won't be able to ever see or directly decrypt it. In order to learn the responder's public key, you can only check if a guess you have for the public key is valid. You could enumerate the entire public key space, but it's so infeasibly large you'd never find it. But if you think the responder might use a specific public key (its identity), say because you know a certain service uses that public key, you could check if your guess is right. That's what this part of the identity hiding property is all about.
How would you do this? The crucial bit here is that 2 Diffie-Hellman operations are done here: ee and es. For ee, you are the initiator and the server transmits it's "e", so you can do this DH easily. For es, you supplied the "e", but want to make guesses about "s". The implicit (possibly empty) transport message after the "es" token has a MAC whose key is derived from ee and es; so if you can guess the responder's public key "s", and you use it and it successfully validates the MAC sent, then you know your guess was right.
Finally, this property is last in the list because it was added last; deferred handshakes (like NK1) were added later. It's not the strongest identity hiding level, 8 is.