Vulnerability: If signer gate is deployed to safe with more than 5 existing modules, safe will be bricked
Severity: medium

Description:
`HatsSignerGate` can be deployed with a fresh safe or connected to an existing safe. In the event that it is connected to an existing safe, it pulls the first 5 modules from that safe to count the number of connected modules. If there are more than 5 modules, it silently only takes the first five. This results in a mismatch between the real number of modules and `enabledModuleCount`, which causes all future transactions to revert.\\nWhen a `HatsSignerGate` is deployed to an existing safe, it pulls the existing modules with the following code:\\n```\\n(address[] memory modules,) = GnosisSafe(payable(_safe)).getModulesPaginated(SENTINEL_MODULES, 5);\\nuint256 existingModuleCount = modules.length;\\n```\\n\\nBecause the modules are requested paginated with `5` as the second argument, it will return a maximum of `5` modules. If the safe already has more than `5` modules, only the first `5` will be returned.\\nThe result is that, while the safe has more than 5 modules, the gate will be set up with `enabledModuleCount = 5 + 1`.\\nWhen a transaction is executed, `checkTransaction()` will get the hash of the first 6 modules:\\n```\\n(address[] memory modules,) = safe.getModulesPaginated(SENTINEL_OWNERS, enabledModuleCount);\\n_existingModulesHash = keccak256(abi.encode(modules));\\n```\\n\\nAfter the transaction, the first 7 modules will be checked to compare it:\\n```\\n(address[] memory modules,) = safe.getModulesPaginated(SENTINEL_OWNERS, enabledModuleCount + 1);\\nif (keccak256(abi.encode(modules)) != _existingModulesHash) {\\n    revert SignersCannotChangeModules();\\n}\\n```\\n\\nSince it already had more than 5 modules (now 6, with HatsSignerGate added), there will be a 7th module and the two hashes will be different. This will cause a revert.\\nThis would be a high severity issue, except that in the comments for the function it says:\\n/// @dev Do not attach HatsSignerGate to a Safe with more than 5 existing modules; its signers will not be able to execute any transactions\\nThis is the correct recommendation, but given the substantial consequences of getting it wrong, it should be enforced in code so that a safe with more modules reverts, rather than merely suggested in the comments.

Impact:
If a HatsSignerGate is deployed and connected to a safe with more than 5 existing modules, all future transactions sent through that safe will revert.

Recommended mitigation:
The `deployHatsSignerGate()` function should revert if attached to a safe with more than 5 modules:\\n```\\nfunction deployHatsSignerGate(\\n    uint256 _ownerHatId,\\n    uint256 _signersHatId,\\n    address _safe, // existing Gnosis Safe that the signers will join\\n    uint256 _minThreshold,\\n    uint256 _targetThreshold,\\n    uint256 _maxSigners\\n) public returns (address hsg) {\\n    // count up the existing modules on the safe\\n    (address[] memory modules,) = GnosisSafe(payable(_safe)).getModulesPaginated(SENTINEL_MODULES, 5);\\n    uint256 existingModuleCount = modules.length;\\n// Add the line below\\n   (address[] memory modulesWithSix,) = GnosisSafe(payable(_safe)).getModulesPaginated(SENTINEL_MODULES, 6);\\n// Add the line below\\n   if (modules.length != moduleWithSix.length) revert TooManyModules();\\n\\n    return _deployHatsSignerGate(\\n        _ownerHatId, _signersHatId, _safe, _minThreshold, _targetThreshold, _maxSigners, existingModuleCount\\n    );\\n}\\n```\\n