Fix state bug from upgrading a shared lock using tryExclusive()

If a shared lock is held when tryExclusive was called, the local lock
state in the client would not be updated properly, instead the call would
return early from this code path. It should have continued the loop to acquire
locks, and it should have updated the local lock map state.

Now it does, this appears to have been a copy-paste error.