feat(deployment): enable chosing party on operations

[rodrigombsoares]

Summary

This PR adds support for deployment and exercise operations to target a specific Canton participant instead of always using Participant[0]. TAR registration now separates CCIP owner, TokenConfig admin, and pool contract owner. Integration tests for tokens use dual EDS (CCIP on P0, token pool on P1) with split ownership.

Features

Participant-aware deployment

• ParticipantIndex on deploy/exercise; ParticipantAt helper
• Wired through coin, burn-mint, and lock-release deploy changesets

MCMS routing

• ProposalDrivenForCaller — proposal mode when submitter cannot ActAs caller (ReadAs ≠ MCMS)
• RegisterTokenPool uses separate MCMS flags for propose (ccip) vs accept/set-pool (admin)

TAR registration (3-party model)

• CcipParty — registry owner; ProposeAdministrator caller
• PoolAdminParty — TokenConfig admin; AcceptAdminRole + SetPool caller (e2e: ccipOwner)
• PoolOwnerParty — pool contract owner; stored in PoolRegistration only
• New RegisterTokenPool changeset; deploy changesets pass PoolAdminParty: CcipOwner

EDS

• Pool-only / partial configs validate with CCIP/CCV disabled (omitempty, required_if=Enabled)

Integration tests (BnM + LnR)

• P0 = ccipOwner, P1 = poolOwner + sender; two EDS instances
• Explicit RegisterTokenPool with PoolAdmin: partyCCIP, PoolOwner: partySender
• LnR: TransferPreapproval on pool owner (P1); balance assertions for poolOwner == sender

Testing

• TestBnMTokenPool_FullSendFlow
• TestLnRTokenPool_FullSendFlow

[friedemannf]

Could you rename these participant/party variables and introduce a third participant/party that is the actual sender?
As-is I think this is blurring the lines between poolOwner/sender, as the poolOwner will also be the party sending the message

[rodrigombsoares]

It is indeed in this case. The client is the one sending and also owning the pool.