fix: repair broken npm install caused by stale package-lock.json

[batuhankocyigit]

fix: repair broken npm install caused by stale package-lock.json

The bug

A fresh clone of this repo cannot be installed. package.json requires:

"@circle-fin/developer-controlled-wallets": "^10.0.1"

but the committed package-lock.json has that package locked to 9.6.0,
which does not satisfy ^10.0.1. Both npm install and npm ci fail
immediately on a clean checkout with:

npm error Conflicting peer dependency: @solana/codecs-strings@2.3.0
npm error node_modules/@solana/codecs-strings
npm error   peerOptional @solana/codecs-strings@"^2.0.0" from @circle-fin/developer-controlled-wallets@10.8.0
npm error   node_modules/@circle-fin/developer-controlled-wallets
npm error     @circle-fin/developer-controlled-wallets@"^10.0.1" from the root project

This isn't cosmetic — .github/workflows/ci.yml runs npm install on
every PR and push to master, so CI is currently broken for everyone, and
any new contributor cloning the repo hits this on their first npm install.

Root cause

Two things compound here:

1. package.json was bumped from the 9.x line to ^10.0.1 at some point
   without regenerating package-lock.json, leaving the lockfile pinned to
   the old 9.6.0.
2. @circle-fin/developer-controlled-wallets@10.x declares a
   peerOptional dependency on @solana/codecs-strings@^2.0.0, while this
   project's Solana-capable wallet tooling elsewhere in the dependency tree
   pulls in @solana/codecs-strings@5.5.1. npm's strict peer resolution
   (used by npm ci, and by npm install once a conflicting lockfile
   exists) refuses to reconcile that on its own.

The fix

• Updated the lockfile so @circle-fin/developer-controlled-wallets
  resolves to 10.8.0 (latest release satisfying ^10.0.1 at the time of
  this PR), matching what package.json already declares.
• Added .npmrc with legacy-peer-deps=true so npm resolves the
  @solana/codecs-strings peerOptional mismatch the same way on every
  machine and in CI, instead of only working by accident depending on
  whether a lockfile happens to already be present.
• package.json's version spec moved from ^10.0.1 to ^10.8.0 — this is
  npm's normal behavior when you npm install <pkg>@<range> and it records
  the resolved version's range; it's a one-line, intentional part of this
  diff, not scope creep.
• No application code changes. I checked every usage of this SDK
  (lib/circle/sdk.ts, lib/circle/gateway-sdk.ts,
  app/api/gateway/transfer/route.ts) against the 10.8.0 type
  definitions — the APIs used are unchanged between 9.6.0 and 10.8.0.

Testing

• npm ci — now exits 0 on a clean checkout (previously failed
  immediately).
• npx tsc --noEmit — no new errors introduced by the SDK bump. (There is
  one pre-existing, unrelated failure in app/api/deposit/route.test.ts —
  it uses describe/it/expect but no test runner is configured in
  devDependencies or package.json scripts. That's a separate issue from
  this dependency fix and I've left it out of this PR to keep the diff
  focused; happy to open a follow-up if that's useful.)
• npm run build — production build completes successfully, all routes
  compile (/api/deposit, /api/gateway/*, /api/transactions,
  /api/wallet, /dashboard, etc.).
• Confirmed unrelated dependencies (eslint, eslint-config-next, etc.)
  are untouched — this was a targeted update of the one out-of-sync
  package, not a full lockfile regeneration, so the diff only touches what's
  necessary to fix the install.

Notes for reviewers

• I deliberately avoided a full rm package-lock.json && npm install,
  since that reflows every "^"-range dependency in the tree to whatever is
  newest today and produces a huge, hard-to-review diff (it also happened
  to surface an unrelated, pre-existing ESLint config crash on this repo,
  which is out of scope here). This diff is scoped to just the one
  dependency that's actually out of sync.