s_currentBridged accounting is performed on non-normalized releaseOrMintIn.amount

[cyberthirst]

given

ccip/contracts/src/v0.8/ccip/pools/GHO/UpgradeableLockReleaseTokenPool.sol

Lines 124 to 146 in d5c6ced

	function releaseOrMint(
	Pool.ReleaseOrMintInV1 calldata releaseOrMintIn
	) external virtual override returns (Pool.ReleaseOrMintOutV1 memory) {
	// This should never occur. Amount should never exceed the current bridged amount
	if (releaseOrMintIn.amount > s_currentBridged) revert NotEnoughBridgedAmount();
	// Reduce bridged amount because tokens are back to source chain
	s_currentBridged -= releaseOrMintIn.amount;
	_validateReleaseOrMint(releaseOrMintIn);
	// Calculate the local amount
	uint256 localAmount = _calculateLocalAmount(
	releaseOrMintIn.amount,
	_parseRemoteDecimals(releaseOrMintIn.sourcePoolData)
	);
	// Release to the recipient
	getToken().safeTransfer(releaseOrMintIn.receiver, localAmount);
	emit Released(msg.sender, releaseOrMintIn.receiver, localAmount);
	return Pool.ReleaseOrMintOutV1({destinationAmount: localAmount});
	}

i think the s_currentBridged should be decremented by localAmount

given that all GHO deployments use 18 decimals it functionally doesn't matter wrt current deployments:

  function _calculateLocalAmount(uint256 remoteAmount, uint8 remoteDecimals) internal view virtual returns (uint256) {
    if (remoteDecimals == i_tokenDecimals) {
      return remoteAmount;
    }

but might screw up the accounting in case of a future deployment/adaptation for a different token