refactor: reorient CLAIM note consumption flow

[partylikeits1983]

This PR reorients the flow in which the CLAIM note is consumed.

This PR reorients the flow from:

CLAIM -> aggfaucet -> (FPI call) bridge_in -> P2ID

CLAIM note is consumed by AggFaucet account, which does an FPI call to bridge to verify merkle proof, if valid creates P2ID note

to:

CLAIM -> bridge_in -> MINT -> aggfaucet -> P2ID

CLAIM note is consumed by AggBridge account which verifies the merkle proof, if valid creates a MINT note, which is then consumed by AggFaucet account in separate tx, which creates P2ID note.

---

This PR adds a mapping to the AggBridge which stores the bytes20 origin token address in the faucet registry as hash(bytes20) -> AccountId.

This is so that when creating the MINT note, the correct network note attachment target can be set. Storing the hash of the destination address as the key in a mapping, where the value is the aggfaucet AccountId is essential, as previously we only stored registered AggFaucets in a mapping like this: AccountId -> bool.

---

Note: Both the MINT note & P2ID note which created by the consumption of the MINT note, both use the PROOF_DATA_KEY (hash of proof data) as their serial numbers.

Resolves #2506

[Fumuran]

Looks great, thank you! I left some nits and questions inline.

This is partial review, I only looked through the MASM code (but mostly in a way of code optimization, not the algorithm correctness).

[mmagician]

Overall looks good!

[mmagician]

It's a bit strange that we have two registries now. I would at least document this better somewhere.

It seems that one is used for bridging out (we have Miden address, we check what's the eth equivalent), while the other is for bridging in (we have eth address, we query the Miden faucet addresss)

[mmagician]

actually this could go right into the spec document. We can merge that PR into the agglayer branch, and have any further PRs against this branch update the spec

[mmagician]

we should add constants for those, similar to https://github.com/0xMiden/miden-base/blob/a1f3b48a2bf384c522fe175fd24ccb82af81b0b2/crates/miden-standards/asm/standards/attachments/network_account_target.masm#L19

[mmagician]

now that we've re-oriented the flow, we could reconsider where the conversion data is stored (i.e. re-consider #2172), but we can do it separately

[mmagician]

while this might be refactored later (TBD on how #2535 progresses), they are currently referring to the same underlying data, let's not duplicate

[mmagician]

we have a constant for this: https://github.com/0xMiden/miden-base/blob/be6ea54f3d7d7e1245906ae19dfcb7602fc4e69f/crates/miden-protocol/asm/shared_utils/util/note.masm#L8

ATTACHMENT_SCHEME_NONE should probably also be added there.

[mmagician]

if this is unused, we should remove the proc

[mmagician]

ah, but this introduces a critical vulnerability - now we just use the miden_claim_amount that is passed in ClaimNoteStorage while completely disregarding the amount that is part of LeafData.
So the proof verifies, and then we forget about EthAmount there and can just mint however many tokens we wish 😁

(PoC here, all tests still pass when minting 10x the amount)