Storage gap variables slightly off from the intended size
The Forta staking system is using upgradeable proxies for its deployment strategy. To avoid storage collisions between contract versions during upgrades, uint256[] private `__gap` array variables are introduced that create a storage buffer. Together with contract state variables, the storage slots should sum up to 50. For example, the `__gap` variable is present in the `BaseComponentUpgradeable` component, which is the base of most Forta contracts, and there is a helpful comment in `AgentRegistryCore` that describes how its relevant `__gap` variable size was calculated:\\n```\\nuint256[50] private \\_\\_gap;\\n```\\n\\n```\\nuint256[41] private \\_\\_gap; // 50 - 1 (frontRunningDelay) - 3 (\\_stakeThreshold) - 5 StakeSubjectUpgradeable\\n```\\n\\nHowever, there are a few places where the `__gap` size was not computed correctly to get the storage slots up to 50. Some of these are:\\n```\\nuint256[49] private \\_\\_gap;\\n```\\n\\n```\\nuint256[47] private \\_\\_gap;\\n```\\n\\n```\\nuint256[44] private \\_\\_gap;\\n```\\n\\nWhile these still provide large storage buffers, it is best if the `__gap` variables are calculated to hold the same buffer within contracts of similar types as per the initial intentions to avoid confusion.\\nDuring conversations with the Forta Foundation team, it appears that some contracts like `ScannerRegistry` and `AgentRegistry` should instead add up to 45 with their `__gap` variable due to the `StakeSubject` contracts they inherit from adding 5 from themselves. This is something to note and be careful with as well for future upgrades.
Provide appropriate sizes for the `__gap` variables to have a consistent storage layout approach that would help avoid storage issues with future versions of the system.
```\\nuint256[50] private \\_\\_gap;\\n```\\n