payments: portal refresh + react-query migration

[owklama]

Refresh of the payments web portal, matching the design patterns from PR #445.

Highlights

• Drop TopBar + WalletDrawer; consolidate into a single sidebar AccountMenu.
• New OverviewView + EarnView; DepositView reworked into a guided two-step flow; status icons on ChannelsView.
• Migrate data fetching to @tanstack/react-query (replaces manual polling in App.tsx).
• Consolidate ABIs under web/src/abi/.
• Extract deposit/withdraw/claim validators into web/src/lib/ with unit tests under web/src/tests/.
• Harden dev-token pinning behind NODE_ENV !== 'production'.

Testing

• pnpm --filter @antseed/payments... typecheck clean.
• pnpm --filter @antseed/payments test — 40 tests pass.
• Manual: overview, earn, channels, deposit, withdraw, theme toggle, legacy ?tab=dashboard redirect.

[Augustas11]

Big refresh — most of it lands well. The bearer-token middleware in server.ts:38–50 correctly gates the new /api/seller-status, /api/seller-activity, and /api/seller-volume-series endpoints (none of them match the GET /api/config / GET /api/transactions skip prefixes), and the daysParam clamp at routes.ts:191 (Math.min(Math.max(parseInt(...) || 30, 1), 90)) cuts off the obvious abuse vector for the log-scanning endpoint.

A few things worth addressing before merge:

1. apps/payments/package.json:3 regresses 0.1.19 → 0.1.18. Almost certainly a merge mistake. Bump it forward (probably to 0.2.0 given the surface area).

2. Removing the V1 legacy emissions client (routes.ts /api/claimable hunk, ~lines 290–340 in the diff) deserves a mention in the PR description. Per INV-45, AntseedEmissionsV2 already combines V1 points server-side via _combinedUserSellerPoints for epoch <= MIGRATION_EPOCH, so dropping the redundant client-side combining is functionally a no-op for end-users — but a smoke test on a wallet with un-claimed pre-MIGRATION_EPOCH points would lock that in. Without the note this looks like a quietly disruptive change for early users.

3. fetchVolumeSeries has no unit tests. It's the biggest new piece of business logic (~80 lines) and includes non-trivial chunk math (LOG_SCAN_CHUNK, FASTEST_SECS_PER_BLOCK heuristic for minBlock), the empty-chunk timestamp peek (routes.ts:172–177), and bigint bucket aggregation. A handful of tests stubbing provider.getLogs + getBlock would catch arithmetic regressions cheaply. The formatUsdc(bucketRaw) boundary preserves precision — that's good — but worth pinning.

4. Cache stampede on first hit. volumeSeriesCache only sets after fetchVolumeSeries resolves, so two concurrent first-time requests will both do the full ~400-chunk RPC scan. A per-key in-flight Promise<> map (mirroring the _buyerLocks pattern in seller-payment-manager.ts:319-328) would give you single-flight semantics for free.

5. Minor: getActiveChannelCount at packages/node/src/payments/evm/channels-client.ts:259-263 will revert if the seller is not registered. Wrapping or documenting that would help — routes.ts:493 calls it as .catch(() => 0) already, but the typed accessor itself doesn't promise that.

6. Document expected RPC cost for ?days=90 in the payments README. At 9500 blocks/chunk × ~43200 blocks/day on Base, a 90-day scan is ~400 getLogs + getBlock calls; the 60s cache mitigates but rate-limited public RPCs will struggle.

Overall the security model is sound and the dev-token gating in server.ts:31-41 correctly hard-codes the prod fallback to randomBytes(32). Good work.