_getReserveRatioScalar() will give a lesser value than expected

Summary

numberOfExpansions = (block.timestamp - config.lastExpansion) / config.expansionFrequency

The calculation divides it by the expansionFrequency, but this will cause significant rounding issues.

If the expansionFrequency is 1 day (as specified in the docs), time may pass without anybody calling the function and the following scenario will be present.

Let's say 30 hours since last expansion and someone decides then to call it, it will be rounded due to the division to be 1 day, producing a smaller value than the hours that've passed.

Root Cause

The root cause is the potential of rounding down numberOfExpansions, which will give a significantly smaller value, depending on how big will be remainder of the division. (6 for 30 hours, 3 for 27 hours, etc)

Internal pre-conditions

mintUBIFromExpansion() need to be callable.

Attack Path

1. Alice calls mintUBIFromExpansion() to create an expansion
2. 30 hours pass and nobody calls the function, Bob sees that he can call mintUBIFromExpansion()
3. Due to the rounding down of the calculation, it will a value equivalent of 24 hours passing.

Impact

The protocol will expand slower than intended, thus less $G will be minted, which will become significant overtime.