feat(api): add account summary endpoint with materialized aggregates

[Ipramking]

Summary

• New AccountSummary Prisma model with composite unique key (address, contractId) — stores totalSent, totalReceived, net, txCount, lastActivityAt; indexed on address and lastActivityAt for O(1) reads
• upsertAccountSummaries() in db.ts: accumulates per-(address, contractId) deltas in memory, then emits one raw PostgreSQL UPSERT per unique pair using NUMERIC arithmetic on string-stored amounts — stays consistent under concurrent ingestion
• Indexer pollOnce calls upsertAccountSummaries right after upsertTransfers so the two tables never diverge
• New src/api/accounts.ts router mounted at /accounts:
  • GET /accounts/:address/summary — returns one row per asset with raw amounts, human-readable display amounts, txCount, and lastActivityAt; optional contractId query filter
• scripts/backfill-account-summaries.ts — truncates and rebuilds AccountSummary from all historical TokenTransfer rows in configurable batches; run via npm run backfill:summaries
• Supertest unit tests covering: single asset, empty result, multi-asset, contractId filter pass-through

Test plan

• npm test passes
• npm run backfill:summaries populates AccountSummary from existing transfers
• GET /accounts/<address>/summary returns one row per asset touched
• GET /accounts/<address>/summary?contractId=<C...> filters to one token
• Ingesting new transfers updates aggregates immediately
• net equals totalReceived - totalSent for all rows
• Existing /transfers/* and /summary/:address endpoints unaffected

Closes #59

[drips-wave]

@Ipramking Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

Clean materialized aggregate.

• Schema: composite @@unique([address, contractId]) is exactly right; amounts stored as decimal String avoids JS BigInt precision loss on serialization.
• upsertAccountSummaries: uses prisma.$executeRaw template-literal form, so every ${…} is a bound parameter — no SQL injection surface. The NUMERIC cast ("totalSent"::NUMERIC + ${sentStr}::NUMERIC) ⇒ TEXT roundtrip is the standard way to do additive math on text-encoded large integers in Postgres.
• net is recomputed at UPDATE time from the row's current totals plus the delta — correctness preserved even if the delta is negative on net.
• In-memory delta accumulation before flushing keeps it to O(unique-addresses) round-trips per batch instead of O(transfers). Right trade-off for the indexer's batched ingestion.
• Backfill script + supertest coverage round it out.

One forward-looking note (not blocking): the per-pair sequential $executeRaw will become the slow path on heavy days; a single multi-row INSERT … ON CONFLICT with unnest(ARRAY[…]) would batch it. Worth filing as a follow-up if backfill turns out to be slow on large historical data.

Merging. Closes #59.