MultiAccount `depositAndAllocateForAccount` function doesn't scale the allocated amount correctly, failing to allocate enough funds
Internal accounting (allocatedBalances) are tracked as fixed numbers with 18 decimals, while collateral tokens can have different amount of decimals. This is correctly accounted for in AccountFacet.depositAndAllocate:\\n```\\n    AccountFacetImpl.deposit(msg.sender, amount);\\n    uint256 amountWith18Decimals = (amount * 1e18) /\\n        (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\\n    AccountFacetImpl.allocate(amountWith18Decimals);\\n```\\n\\nBut it is treated incorrectly in MultiAccount.depositAndAllocateForAccount:\\n```\\n    ISymmio(symmioAddress).depositFor(account, amount);\\n    bytes memory _callData = abi.encodeWithSignature(\\n        "allocate(uint256)",\\n        amount\\n    );\\n    innerCall(account, _callData);\\n```\\n\\nThis leads to incorrect allocated amounts.
Scale amount correctly before allocating it:\\n```\\n    ISymmio(symmioAddress).depositFor(account, amount);\\n+   uint256 amountWith18Decimals = (amount * 1e18) /\\n+       (10 ** IERC20Metadata(collateral).decimals());\\n    bytes memory _callData = abi.encodeWithSignature(\\n        "allocate(uint256)",\\n-       amount\\n+       amountWith18Decimals\\n    );\\n    innerCall(account, _callData);\\n```\\n
Similar to 222 from previous audit contest, the user expects to have full amount deposited and allocated, but ends up with only dust amount allocated, which can lead to unexpected liquidations (for example, user is at the edge of liquidation, calls depositAndAllocate to improve account health, but is liquidated instead). For consistency reasons, since this is almost identical to 222, it should also be high.
```\\n    AccountFacetImpl.deposit(msg.sender, amount);\\n    uint256 amountWith18Decimals = (amount * 1e18) /\\n        (10 ** IERC20Metadata(GlobalAppStorage.layout().collateral).decimals());\\n    AccountFacetImpl.allocate(amountWith18Decimals);\\n```\\n