Inconsistent state of a lock
"inconsistent" here means basically the internal implementation is not reflecting the reality of thread activation and lock availability. aka "defective". ie its not functioning correctly as a thread lock. eg the lock may indicate "active" but no thread has acquired the lock or the lock indicates "inactive" but some thread acquired a lock.
the contradiction is that according to "deadlock free", a lock will eventually be acquired by at least some thread that requests it. but if its in an inconsistent state then some thread is running but the lock indicates that nothing is locked. but then any new thread cannot succeed in obtaining the lock (without running at the same time as A).


note a wrinkle/subtlety from an online ref[1] that closely matches the book exposition (same authors):


  Note that a program can still deadlock even if each of the locks it
  uses satisﬁes the no-deadlock property. For example, consider threads A and
  B that share locks 0 and 1. First, A acquires 0 and B acquires 1. Next,
  A tries to acquire 1 and B tries to acquire 0. The threads will deadlock
  because each one waits for the other to release its lock


[1] Multiprocessor Synchronization and Concurrent 
Data Structures Maurice Herlihy / Nir Shavit