False positive on not-pipelined block in ThreadNet

Reproducible in branch `temp-pipeline-rollback-error` with
```
cabal run ouroboros-consensus-cardano-test:test:test -- -p "Cardano ThreadNet.simple convergence" --quickcheck-replay=805127
```

The leader schedule is:
```
(79,[c1]),(80,[c1]),(81,[]),(82,[]),(83,[]),(84,[]),(85,[]),(86,[]),(87,[]),(88,[c0])
```

The flow of the test is as follows:
```
Slot 79
Node-1 forges block ca3385, with slotNo 79 and blockNum 80
Node-1 announces ca3385 via Pipelining
Node-1 sends the block to Node-0 via chainsync
Node-0 receives ca3385 and selects it
Node-0 requests new header to Node-1
Node-1 requests new header to Node-0

Slot 80
Node-1 forges block ea1ea5, with slotNo 80 and blockNum 81
Node-1 announces ea1ea5 via Pipelining
Node-1 sends ea1ea5 to Node-0 via chainsync <----- Message delayed for 8 slots

Slot 81
Slot 82
Slot 83
Slot 84
Slot 85
Slot 86
Slot 87

Slot 88
Node-0 receives the `MsgRollForward` message with ea1ea5
Node-0 selects ea1ea5
Node-0 forges block d92d9, with slotNo 88 and blockNum 81
Node-0 selects d92d9, therefore rolling back
Node-0 doesn't announce d92d9 via Pipelining due to roll back
```

The test fails because it expected that Node-0 pipelines d92d9, however as it was rolling back it should not pipeline it (see [`isPipelineable`](https://github.com/input-output-hk/ouroboros-network/blob/f2d0521658d75ad8e6eccfdae1264279bdf82cd2/ouroboros-consensus/src/Ouroboros/Consensus/Storage/ChainDB/Impl/ChainSel.hs#L1256)) and the test error is a false positive.

Even further, this happened because VRF(ea1ea5) < VRF(d92d9), but if it was the other way around, the same error would be thrown because the block was forged but not pipelined as it wouldn't be adopted because it would lose the VRF against the current selection.

There is probably no harmful error on the real code, just the test not being accurate enough.