Target signature threshold can be bypassed leading to minority TXs
`checkTransaction()` is the enforcer of the HSG logic, making sure signers are wearers of hats and so on. The check below makes sure sufficient hat wearers signed the TX:\\n```\\n        uint256 validSigCount = countValidSignatures(txHash, signatures, signatures.length / 65);\\n                // revert if there aren't enough valid signatures\\n        if (validSigCount < safe.getThreshold()) {\\n                     revert InvalidSigners();\\n         }\\n```\\n\\nThe issue is that the safe's threshold is not guaranteed to be up to date. For example, initially there were 5 delegated signers. At some point, three lost eligibility. `reconcileSignerCount()` is called to update the safe's threshold to now have 2 signers. At a later point, the three signers which lost eligibility regained it. At this point, the threshold is still two, but there are 5 valid signers, so if targetThreshold is not below 5, they should all sign for a TX to be executed. That is not the case, as the old threshold is used. There are various scenarios which surface the lack of synchronization between the wearer status and safe's stored threshold.
Call `reconcileSignerCount()` before the validation code in `checkTransaction()`.
```\\n        uint256 validSigCount = countValidSignatures(txHash, signatures, signatures.length / 65);\\n                // revert if there aren't enough valid signatures\\n        if (validSigCount < safe.getThreshold()) {\\n                     revert InvalidSigners();\\n         }\\n```\\n