Cache /api/stellar/liquidity lookups (#375)

[Vyacheslav-Tomashevskiy]

Closes #375.

What was actually missing

Unlike #374's /api/stellar/rate (whose sibling rates.ts already had an in-memory cache, so that one just needed the HTTP layer), /api/stellar/liquidity had no caching anywhere. Every single request called server.liquidityPools().forAssets(asset).limit(1).order("desc").call() straight against Horizon - a real network round-trip, every time.

Change

• src/lib/stellar.ts: new getLiquidityPool(assetCode) moves the lookup logic out of the route handler and wraps it with a short-TTL (60s) in-memory cache keyed by uppercased asset code - same pattern already used for rates in src/lib/rates.ts. The "no issuer configured" / "no pool found" answers get cached too: unlike rates.ts's hardcoded fallback rate (which is a degraded substitute for a live value and deliberately isn't cached that way), "this asset has no pool" is a stable, real answer that won't change until an issuer gets configured or a pool gets created - there's no reason to keep re-asking Horizon for it.
• src/app/api/stellar/liquidity/route.ts: now calls getLiquidityPool() instead of querying Horizon directly, and sets Cache-Control on every response:
  • private, max-age=60, stale-while-revalidate=120 on a successful lookup - private (not public), since this route requires a session and a shared/CDN cache must never serve one user's authenticated response to a different, unauthenticated request.
  • no-store on the 401/400/500 paths, which weren't setting any Cache-Control before either.

Added src/lib/__tests__/stellar-liquidity-cache.test.ts (6 tests, mocking @stellar/stellar-sdk's Horizon.Server so no real network calls happen): a fresh asset hits Horizon once, a second lookup for the same asset is served from cache without a second Horizon call, different asset codes cache independently, an asset with no configured issuer never touches Horizon at all, that "no issuer" answer is cached too, and a genuinely empty pool result is reported with a reason. Each test imports a fresh copy of the module (vi.resetModules()) so the module-private cache doesn't leak state between tests.

Added src/app/api/stellar/liquidity/__tests__/route.test.ts (6 tests, mocking @/lib/auth and @/lib/stellar): correct Cache-Control on a live and a cached lookup, a null-pool answer still gets cached, and unauthenticated/missing-param/error paths all get no-store without ever calling getLiquidityPool.

Verification

• Temporarily restored the known missing isValidStellarPublicKey import (fix(validations): restore broken isValidStellarPublicKey import; feat: add /api/stellar/fee-estimate #529) to run this locally, since validations.ts won't load on main without it. New test files: 12/12 passing. Reverted before this commit (git diff on validations.ts is empty in this PR).
• Full suite: 76 passed (the pre-existing 64 plus these 12), same 2 pre-existing failures from a bad fixture address in validations.test.ts, unrelated to this change.
• npm run dev + curl: unauthenticated and missing-param requests to the live route both return the expected status with Cache-Control: no-store, confirming the header logic runs on a real server. Couldn't drive the 200 path live in this sandbox (no real Supabase instance to back a session), so that path - and the actual caching behavior - is covered by the unit tests instead.
• tsc --noEmit - no new errors (same pre-existing fix(validations): restore broken isValidStellarPublicKey import; feat: add /api/stellar/fee-estimate #529 and an unrelated transactions/[id] test type-mismatch present on main).
• eslint - clean.

/claim

[vercel]

Someone is attempting to deploy a commit to the codex723's projects Team on Vercel.

A member of the Team first needs to authorize it.