The problem that you're facing is that of network partition combined with the fact that you allow a subset of lockers to participate in the sequence of processes that finalise the state.
You can end up with a fork if you allow a subset of all allocated lockers to finalise the state, due to network partition. If you require a majority to participate, you will get a stalled consensus until the partition resolves itself.
Nothing the lockers say finalizes the state. A locker signed transaction needs to be confirmed by a majority of nodes to be accepted.
Like previously stated, consensus is delayed until approved by the majority, even with the risk of voiding the round. The fact that you keep mentioning a fork means that you're not very clear on how the algorithm works. Did you understand this from the consensus section? It could be the paper is not clear on it, but please try reading it again.