Vulnerability: Signers can brick safe by adding unlimited additional signers while avoiding checks
Severity: high

Description:
There are a number of checks in `checkAfterExecution()` to ensure that the signers cannot perform any illegal actions to exert too much control over the safe. However, there is no check to ensure that additional owners are not added to the safe. This could be done in a way that pushes the total over `maxSigners`, which will cause all future transactions to revert.\\nThis means that signers can easily collude to freeze the contract, giving themselves the power to hold the protocol ransom to unfreeze the safe and all funds inside it.\\nWhen new owners are added to the contract through the `claimSigner()` function, the total number of owners is compared to `maxSigners` to ensure it doesn't exceed it.\\nHowever, owners can also be added by a normal `execTransaction` function. In this case, there are very few checks (all of which could easily or accidentally be missed) to stop us from adding too many owners:\\n```\\nif (safe.getThreshold() != _getCorrectThreshold()) {\\n    revert SignersCannotChangeThreshold();\\n}\\n\\nfunction _getCorrectThreshold() internal view returns (uint256 _threshold) {\\n    uint256 count = _countValidSigners(safe.getOwners());\\n    uint256 min = minThreshold;\\n    uint256 max = targetThreshold;\\n    if (count < min) _threshold = min;\\n    else if (count > max) _threshold = max;\\n    else _threshold = count;\\n}\\n```\\n\\nThat means that either in the case that (a) the safe's threshold is already at `targetThreshold` or (b) the owners being added are currently toggled off or have eligibility turned off, this check will pass and the owners will be added.\\nOnce they are added, all future transactions will fail. Each time a transaction is processed, `checkTransaction()` is called, which calls `reconcileSignerCount()`, which has the following check:\\n```\\nif (validSignerCount > maxSigners) {\\n    revert MaxSignersReached();\\n}\\n```\\n\\nThis will revert as long as the new owners are now activated as valid signers.\\nIn the worst case scenario, valid signers wearing an immutable hat are added as owners when the safe's threshold is already above `targetThreshold`. The check passes, but the new owners are already valid signers. There is no admin action that can revoke the validity of their hats, so the `reconcileSignerCount()` function will always revert, and therefore the safe is unusable.\\nSince `maxSigners` is immutable and can't be changed, the only solution is for the hat wearers to renounce their hats. Otherwise, the safe will remain unusable with all funds trapped inside.

Impact:
Signers can easily collude to freeze the contract, giving themselves the power to hold the protocol ransom to unfreeze the safe and all funds inside it.\\nIn a less malicious case, signers might accidentally add too many owners and end up needing to manage the logistics of having users renounce their hats.

Recommended mitigation:
There should be a check in `checkAfterExecution()` that ensures that the number of owners on the safe has not changed throughout the execution.\\nIt also may be recommended that the `maxSigners` value is adjustable by the contract owner.