support Sui in token adapter interface

[FelixFan1992]

Describe your changes

..

Issue ticket number and link

..

Describe highly relevant files or code snippets that are critical in the review

..

Are there other PRs that should be merged first?

..

[Copilot]

Pull request overview

This PR introduces a Sui implementation of the CCIP tokensapi.TokenAdapter/TokenRefResolver so generic token/pool deployment & configuration flows can operate against Sui CCIP token pools using Sui’s coin-type and Move package/object addressing model.

Changes:

• Added SuiTokenAdapter implementing key adapter behaviors (address serialization, token-decimals derivation, pool rate-limit updates, and authority transfer via MCMS proposal ops).
• Added resolver logic for Sui token refs (coin type strings) and token pool refs (pool package IDs → typed AddressRef with symbol qualifier).
• Added unit tests covering helper/utility behavior for the new adapter.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
deployment/adapters/token_adapter.go	Adds the Sui token adapter implementation and related helpers.
deployment/adapters/token_adapter_test.go	Adds unit tests for adapter helpers and basic behaviors.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

deployment/adapters/token_adapter.go:299

• ResolveTokenPoolRef can return a pool AddressRef with an empty Qualifier when the datastore entry is missing a symbol label. Downstream calls (e.g. resolveSuiPoolObjects) require the symbol and will fail later with a less actionable error; it’s better to detect and error (or skip) here when a pool ref is found but no symbol label is present.

		return datastore.AddressRef{
			ChainSelector: chainSelector,
			Type:          r.Type,
			Address:       r.Address,
			Qualifier:     symbolFromLabels(r),

deployment/adapters/token_adapter.go:948

• normalizeCoinType only recognizes the lowercase 0x prefix and will produce invalid coin types for inputs like 0X... (becoming 0x0X...). It also turns an empty string into 0x, which is never a valid coin type.

func normalizeCoinType(s string) string {
	if strings.HasPrefix(s, "0x") {
		return s
	}
	return "0x" + s
}

deployment/adapters/token_adapter.go:376

• ConfigureTokenForTransfersSequence iterates over input.RemoteChains (a map), which produces nondeterministic ordering. That makes the generated MCMS BatchOps/transactions order unstable across runs, which is undesirable for proposal reproducibility and can lead to flaky tests or mismatched expected proposal hashes.

			batchOps := make([]mcmstypes.BatchOperation, 0)
			for remoteSelector, rc := range input.RemoteChains {
				if err := rc.Validate(); err != nil {
					return sequences.OnChainOutput{}, fmt.Errorf("remote chain config for selector %d: %w", remoteSelector, err)
				}

deployment/adapters/token_adapter.go:720

• suiPoolTypeFromStr treats lnr as a supported pool type, but this adapter currently doesn’t implement LnR handling in key flows (e.g., DeployTokenPoolForToken, SetTokenPoolRateLimits, UpdateAuthorities). Accepting lnr here makes failures happen later and with less specific errors.

	case "lnr", string(suideploy.SuiLnRTokenPoolType):
		return datastore.ContractType(suideploy.SuiLnRTokenPoolType), nil

deployment/adapters/token_adapter_test.go:122

• Consider adding test coverage for additional normalizeCoinType edge cases (e.g. uppercase 0X prefix and empty string) to prevent regressions, since callers may pass user-provided coin type strings.

func TestNormalizeCoinType(t *testing.T) {
	t.Parallel()
	require.Equal(t, "0x1::m::T", normalizeCoinType("0x1::m::T"))
	require.Equal(t, "0x1::m::T", normalizeCoinType("1::m::T"))
}