chore: refactor AccountVaultDelta to track generic assets

[PhilippGackstatter]

Summary

AccountVaultDelta no longer splits vault changes into a fungible and a non-fungible half. It now stores a single map of generic AssetDelta entries keyed by AssetId, which matches how the transaction kernel already reports vault changes.

Changes

AccountVaultDelta is now BTreeMap<AssetId, AssetDelta> with AssetDelta moving to miden-protocol.

Commitment format is unchanged.

read_from now routes through the validating new constructor, so a crafted byte stream that lists the same asset in both the added and the removed section is rejected.

closes #3175

[zeapoz]

Looks good! No major complaints, but I think we could return the previous (overwritten) value and pass it down the call stack

[mmagician]

LGTM, with one point to discuss: we used to have normalization for non-zero fungible assets as:

// Only track non-zero amounts.
if delta != 0 {
    entry.insert(delta);
}

which is now gone.

This means "no net change" & "empty delta" used to be the same, and with this PR that's no longer the case.

Also the kernel only commits to entires in the map, so before building a delta containing an Add(amount=0) would still match the kernel-computed commitment. Now, Rust side will contain an entry while the kernel can never emit such a delta.

[PhilippGackstatter]

This means "no net change" & "empty delta" used to be the same, and with this PR that's no longer the case.

Also the kernel only commits to entires in the map, so before building a delta containing an Add(amount=0) would still match the kernel-computed commitment. Now, Rust side will contain an entry while the kernel can never emit such a delta.

Good point, thanks for bringing this up!

I think the need for this extra logic went away with #2630.

For example, consider the case of asset 1 in this test setup:

protocol/crates/miden-testing/src/kernel_tests/tx/test_account_update.rs

Lines 351 to 359 in 134cc1f

	/// Tests that increasing, decreasing the amount of a fungible asset results in the correct update.
	///
	/// - Asset0 starts at 300, is increased by 100 and decreased by 200 -> Delta: -100, Patch: 200.
	/// - Asset1 starts at 200, is increased by 100 and decreased by 100 -> Delta: 0, Patch: None.
	/// - Asset2 starts at 100, is increased by 200 and decreased by 100 -> Delta: 100, Patch: 200.
	/// - Asset3 starts at MAX, is decreased by MAX -> Delta: -MAX, Patch: 0.
	/// - Asset4 starts at 0, is increased by MAX -> Delta: MAX, Patch: MAX.
	#[tokio::test]
	async fn fungible_asset_update() -> anyhow::Result<()> {

The tx kernel tracks [INIT_VALUE, CURRENT_VALUE]. Since the asset is increased and decreased by the same amount, init and current value end up the same. When computing the delta, entries whose values are the same are skipped. This means no event for asset1 is emitted and it is not added to the AccountVaultDelta by the VaultUpdateTracker.

In other words, the special Rust logic is no longer necessary because the consistency between the in-kernel delta and the host delta is guaranteed by constructing the host delta from the in-kernel delta with normalization in mind.