Fix two pre-existing type errors breaking next build on main

[Bryandero98]

Unrelated to any feature work — found while investigating why PR #215's CI kept failing. Confirmed on a clean checkout of main with no other changes: npm run build / npx tsc --noEmit currently fail before this fix.

The two fixes

1. getPoolHistory's return type was missing []. Declared as Promise<{ date: string; tvl: string; truncated?: boolean }> (a single object), but every real return path — the success path (Array.from(dailyMap.entries())...map(...)) and the catch-all [] — is an array. TvlChart.tsx's setData(history) surfaces this as Type error: Argument of type '{...}' is not assignable to parameter of type 'SetStateAction<TvlDataPoint[]>'. Existing tests in soroban.service.test.ts already assert array results (.resolves.toEqual([...])), so this is a pure type-annotation fix with no behavior change.
2. Account (from @stellar/stellar-sdk) is used in 4 places in soroban.ts (Promise<Account>, Map<string, { account: Account; ... }>) but was never imported — error TS2304: Cannot find name 'Account'.

What's left (not fixed here, on purpose)

After these two, tsc --noEmit still reports one more, unrelated error: useLeaderboard.ts:24 calls sorobanService.getLeaderboard(offset, limit, sortKey, search) with a 4th argument, but getLeaderboard only accepts 3. The frontend search UI (debounced input, searchQuery state) is fully built expecting this to work — it's incomplete backend feature work, not a typo, so I didn't guess at the filtering semantics. Flagging it here so it doesn't get lost; happy to take a stab at it in a follow-up if someone can confirm what "search" should match against (address? nothing else obviously identifies an entry).

Testing

• npx tsc --noEmit: down to just the useLeaderboard.ts error above.
• npx vitest run src/lib/soroban.service.test.ts src/lib/soroban.test.ts: same pass/fail counts before and after this change (3 pre-existing failures in getLeaderboard's boostUtilization assertions, unrelated to either fix here — confirmed by running the same suite against untouched main).

[netlify]

❌ Deploy Preview for spiffy-melomakarona-eb1e8a failed.

Name	Link
🔨 Latest commit	cf7b635
🔍 Latest deploy log	https://app.netlify.com/projects/spiffy-melomakarona-eb1e8a/deploys/6a8dff3737df1e0008324edc

[netlify]

❌ Deploy Preview for smart-drop failed.

Name	Link
🔨 Latest commit	cf7b635
🔍 Latest deploy log	https://app.netlify.com/projects/smart-drop/deploys/6a8dff377ca3dc00098390ef

[Bryandero98]

Update + a transparency note on the Netlify failures:

Pushed a fix for the third pre-existing bug this PR originally flagged but left alone: useLeaderboard.ts was already calling sorobanService.getLeaderboard(offset, limit, sortKey, search) with a search argument that getLeaderboard() didn't accept (next build type-checks the whole app, so this alone was enough to fail the build regardless of the other two fixes). Added search to getLeaderboard, threaded through to both the API path (as a search query param) and the event-scan fallback (case-insensitive substring filter on address, applied before pagination). Added test coverage for both paths. next build now passes locally end-to-end.

Separately, I dug into why Netlify itself was still failing even after that fix. I don't have dashboard access to Netlify's actual build logs, but the same commit also triggers a deploy GitHub Actions job (publishing to gh-pages), and that log is public. It fails at the npm ci step, before any build/type-check runs:

npm error `npm ci` can only install packages when your package.json and package-lock.json ... are in sync.
npm error Missing: @next/bundle-analyzer@15.5.24 from lock file
npm error Missing: webpack-bundle-analyzer@4.10.1 from lock file
... (11 more missing transitive deps)

This reproduces on main itself, not just this branch — package-lock.json is out of sync with package.json (missing the @next/bundle-analyzer subtree) repo-wide. Given the ~25s fail time on Netlify's own checks for this PR (too fast to be a real build), I'm confident this is the same root cause there.

I didn't fix the lockfile myself: I only have npm 11 / Node 24 locally, and regenerating package-lock.json with a newer toolchain than CI's (npm 10.8.2 / Node 20.20.2, per the Actions log) produced a much larger diff than the missing packages alone would explain — not something I want to commit without verifying against the same npm/Node version CI actually uses. Flagging it here with the exact missing packages so whoever has that environment can run a plain npm install and commit the refreshed lock file — that should unblock both this PR's Netlify preview and main's own deploy.