Remove the stellar-sdk npm aliases and deduplicate stellar-sdk copies

[aristidesstaffieri]

Summary

The dependency tree contains four copies of @stellar/stellar-sdk. Two of them exist
because we install the same package twice under npm aliases. The other two come from
third-party packages that pin old SDK versions. All four are reachable from the built
extension.

This costs bundle size, install size, and supply-chain surface. This issue proposes
removing the aliases and reducing the number of copies.

Current state

Package name in node_modules	Version	Comes from	Size on disk
stellar-sdk (alias)	16.0.0-rc.1	our code, ~100 files	33M
stellar-sdk-next (alias)	16.0.0-rc.1	our code, 5 files	33M
@stellar/stellar-sdk	15.0.1	@stellar/typescript-wallet-sdk-km@3.0.1 (background / key manager)	17M
@stellar/stellar-sdk (nested)	11.3.0	soroswap-router-sdk@1.4.6 (popup swap)	3.8M

The aliases are declared in four workspaces:
extension/package.json:87, @shared/constants/package.json:6,
@shared/api/package.json:12, @shared/helpers/package.json:7.

Note that Yarn already treats the two aliases as one package at resolution time:

yarn.lock:22301
"stellar-sdk-next@npm:@stellar/stellar-sdk@16.0.0-rc.1, stellar-sdk@npm:@stellar/stellar-sdk@16.0.0-rc.1":

One locator, two descriptors. The duplication happens only at link time, because the
two package names are different, so they are installed into two directories. Webpack
then builds two separate module graphs from them. Yarn cannot merge this; only removing
the alias can.

Why the alias exists today

stellar-sdk-next was added to stage a protocol upgrade. The idea was to point -next
at a release candidate while stellar-sdk stayed on the stable release, then select one
per network at runtime with getSdk(networkPassphrase) (@shared/helpers/stellar.ts:22).

That is not what happens now:

• Both aliases are pinned to the same version. We always bump them together.
• isNextSdk is [""].includes(networkPassphrase), which is always false. The -next
  branch is dead code.

So the second copy currently gives us nothing.

Proposed change

1. Replace "stellar-sdk": "npm:@stellar/stellar-sdk@<version>" with
   "@stellar/stellar-sdk": "<version>" in the four workspace package.json files.
2. Update the imports. About 100 files import stellar-sdk. This is a mechanical
   find-and-replace.
3. Remove stellar-sdk-next and the 5 imports that use it. Keep getSdk() as a
   one-line function that always returns the single SDK, so the call sites do not
   change in this PR.
4. Reduce the third-party copies:
   • @stellar/typescript-wallet-sdk-km@3.0.1 pins SDK 15.0.1. Check for a newer
     release built against SDK 16. If there is none, open an upstream request to make
     @stellar/stellar-sdk a peer dependency with a range, not an exact pin.
   • soroswap-router-sdk@1.4.6 pins ^11.3.0. Check whether a newer release exists.
   • A Yarn resolutions entry can force a single version, but this touches the key
     manager, which is on the signing path. Do not do this without testing account
     import, account recovery, and hardware wallet signing.
5. Measure the bundle before and after with webpack-bundle-analyzer, and record the
   numbers in the PR.

Trade-off to decide

Removing stellar-sdk-next also removes the mechanism we would use for the next
protocol upgrade. Two options:

• (a) Remove it now, add it back only during a transition. Add the alias when we
  need to run an RC beside the stable SDK, then delete it after activation.
• (b) Keep it. Accept a permanent duplicate copy for a mechanism that is used for a
  few weeks per protocol release.

Recommendation: (a). The current setup pays the cost all the time.

Verification

• yarn install and confirm node_modules has fewer @stellar/stellar-sdk copies.
• yarn tsc, yarn lint, yarn test all pass.
• yarn build (webpack) succeeds, and lavamoat / allowScripts still resolves the
  stellar-sdk>stellar-base>sodium-native path, which is keyed by package name
  (extension/package.json:125-126). This path changes when the alias is removed.
• Manual check of the key manager: create account, import account, recover account.
• Manual check of a swap, which uses soroswap-router-sdk.
• e2e suite passes.

Out of scope

Runtime behaviour changes. This is a packaging change only.