[HeesungB]

Summary

Sync the SDK with the window.adena.cosmos sub-namespace and the multi-chain AddEstablish flow already exposed by the Adena wallet extension. The wallet's inject script has a TODO ("until the SDK enum catches up") — this PR is that catch-up.

Background

• The wallet exposes window.adena.cosmos (enable / getKey / signAmino / signDirect / sendTx plus three offline signers) and AddEstablish(name, chainIds?), but the SDK types were missing or incorrect, forcing dApps to cast.
• Crucially, the cosmos methods were typed as if they returned raw values, but the runtime returns AdenaResponse wrappers ({ status, type, code, message, data }). dApps that trusted the SDK types would break at runtime.

Changes

1. Cosmos sub-namespace types

• New AdenaCosmos interface: enable / getKey / signAmino / signDirect / sendTx all return Promise<WalletResponse<T>> to match the wallet's runtime contract.
• All three offline signers (getOfflineSigner, getOfflineSignerOnlyAmino, Keplr-compatible getOfflineSignerAuto). The auto variant resolves isNanoLedger first and returns an amino-only signer for Ledger accounts, full amino+direct otherwise. These follow the CosmJS OfflineSigner contract (bare values, throw on failure).
• Response type aliases exported: EnableCosmosResponse, GetCosmosKeyResponse, SignCosmosAminoResponse, SignCosmosDirectResponse, SendCosmosTxResponse.
• AdenaWallet.cosmos?: AdenaCosmos — optional so existing dApps keep compiling.

2. WalletResponseExecuteType entries

• Adds ENABLE_COSMOS, GET_COSMOS_KEY, SIGN_COSMOS_AMINO, SIGN_COSMOS_DIRECT, SEND_COSMOS_TX plus matching WalletExecuteMessageInfo rows. Values are 1:1 with the wallet's interim CosmosResponseExecuteType const so it can switch over.

3. Multi-chain AddEstablish

• AddEstablishOptions.chainIds widened from string[] to string | string[] so single-chain callers don't need to wrap in an array.
• AdenaWalletProvider.addEstablish forwards chainIds as the second argument.
• A dApp can request access to multiple chains (e.g. Gno + AtomOne) in a single approval popup.

4. Tests

• wallet-types-cosmos.test.ts — verifies the 5 enum values and WalletMessageInfo registration.
• adena-cosmos.test.ts — verifies the AdenaCosmos implementation responds with wrappers and that getOfflineSignerAuto is callable.
• add-establish.test.ts — covers both single-string and array chainIds forwarding.

5. Version

• @adena-wallet/sdk 0.0.14 → 0.0.15.

Compatibility

• AdenaWallet.cosmos is optional — works with wallet builds that don't expose the cosmos namespace.
• Calling addEstablish without chainIds keeps the legacy "approve current chainGroup" behavior.
• Possible break: any dApp written against the previous (incorrect) SDK types that assumed raw return values from cosmos methods will need to read response.data. In practice that code was already broken at runtime, since the wallet has always returned wrappers.

Test plan

• yarn workspace @adena-wallet/sdk tsc --noEmit
• yarn workspace @adena-wallet/sdk lint
• yarn workspace @adena-wallet/sdk test (28 suites / 78 tests pass)
• End-to-end: locally built wallet + demo dApp — adena.cosmos.enable(['atomone-1']), adena.cosmos.getKey('atomone-1'), adena.AddEstablish('demo', ['atomone-1', 'portal-loop']) resolved through a single approval popup
• Verify getOfflineSignerAuto returns an amino-only signer for Ledger accounts and a full amino+direct signer otherwise

🤖 Generated with Claude Code