Add note regarding ERC4626 fees mechanics

Author: immrsd

content/contracts-cairo/3.x/api/erc20.mdx

@@ -1139,6 +1139,8 @@ Allows contracts to hook logic into deposit and withdraw transactions. This is w
 
 ERC4626 preview methods must be inclusive of any entry or exit fees. Fees are calculated using [FeeConfigTrait](#ERC4626Component-FeeConfigTrait) methods and automatically adjust the final asset and share amounts. Fee transfers are handled in `ERC4626HooksTrait` methods.
 
+When a vault implements fees on deposits or withdrawals (either in shares or assets), fee transfers must be handled in these hooks by library clients. This creates a non-atomic operation flow consisting of multiple state-changing steps: transferring assets, minting or burning shares, and transferring (or minting) fees. Between these steps, the vault's state is temporarily inconsistent: the asset-to-share conversion rate does not accurately reflect the vault's final state until all steps have completed. Therefore, it is critical to avoid making any external calls (including to the vault contract itself) or querying conversion rates during hook execution.
+
 Special care must be taken when calling external contracts in these hooks. In that case, consider implementing reentrancy protections. For example, in the `withdraw` flow, the `withdraw_limit` is checked **before** the `before_withdraw` hook is invoked. If this hook performs a reentrant call that invokes `withdraw` again, the subsequent check on `withdraw_limit` will be done before the first withdrawal's core logic (e.g., burning shares and transferring assets) is executed. This could lead to bypassing withdrawal constraints or draining funds.
 
 See the [ERC4626AssetsFeesMock](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/test_common/src/mocks/erc4626.cairo#L253) and [ERC4626SharesFeesMock](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/test_common/src/mocks/erc4626.cairo#L426) examples.

content/contracts-cairo/3.x/api/governance.mdx

@@ -186,9 +186,7 @@ Delay between when a proposal is created and when the vote starts. The unit this
 
 This can be increased to leave time for users to buy voting power, or delegate it, before the voting of a proposal starts.
 
-NOTE: While this function returns a u64 value, timepoints must fit into u48 according to
-the EIP-6372 specification. Consequently this value must fit in a u48 (when added to the
-current clock).
+While this function returns a u64 value, timepoints must fit into u48 according to the EIP-6372 specification. Consequently this value must fit in a u48 (when added to the current clock).
 </APIItem>
 
 <APIItem

content/contracts-cairo/3.x/api/utilities.mdx

@@ -276,8 +276,7 @@ Requirements:
 
 - This function MUST always be non-decreasing.
 
-NOTE: While this function returns a u64 value, timepoints must fit into u48 according to
-the EIP-6372 specification.
+While this function returns a u64 value, timepoints must fit into u48 according to the EIP-6372 specification.
 </APIItem>
 
 <APIItem