test(integration): add docker-compose harness and integration test suite

[codefather2026]

SummaryAdds a Docker-based integration test harness for real Postgres-backed API testing.
Introduces a docker-compose.test.yml stack for Postgres + Wraith API with deterministic ports and API-only test mode.
Adds tests/integration/ Vitest coverage for seeded end-to-end scenarios including transfers, transaction lookups, and account summary aggregation.
Updates CI to boot the integration stack on every PR, run npm run test:integration, and tear the stack down afterward.
Adds a /accounts/:address/summary alias and fixes the summary query to target the Prisma schema-qualified Postgres table.
Related issue

Type of changeBug fix
New feature
Refactor
Docs
Tests
CI / tooling
ChecklistI have read CONTRIBUTING.md
npx tsc --noEmit passes
npm run build passes
I added / updated tests where relevant
I updated docs where relevant
If you want, I can also turn this into a slightly more polished PR body with a short “How to test” section.

[drips-wave]

@codefather2026 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]

Heads up @codefather2026 — this developed a merge conflict against package-lock.json after #64 (TypeDoc) just merged. Could you:

git fetch origin main
git rebase origin/main
# resolve any package-lock conflicts (the safest is `rm package-lock.json && npm install` then commit)
git push --force-with-lease

Once the conflict is resolved I'll merge straight away — the diff itself is great.

[codefather2026]

conflict resolved

[Miracle656]

Thanks for the rebase — MERGEABLE is back. The docker-compose harness is solid:

• docker-compose.test.yml: Postgres 16-alpine + Wraith API with healthchecks, deterministic ports (55432, 3300), SKIP_INDEXER=true so seeded fixtures don't fight a running indexer.
• tests/integration/api.test.ts: real fetch against the mapped port; five scenarios covering filtered incoming, paginated address history, summary aggregation, tx-hash lookup, and account exclusion. Expectations are deterministic (integration-002, integration-001 event ID ordering, exact displayNet strings) — solid coverage.
• tests/integration/setup.ts waits on /healthz before seeding, deletes + recreates rows so the test is idempotent across reruns.
• src/db.ts: FROM "TokenTransfer" → FROM "wraith"."TokenTransfer" is the right fix for Prisma multiSchema — raw SQL must use the schema-qualified name.

Two things to resolve before merge:

1. Endpoint-shape collision with #89

#89 landed a few hours ago and mounted a brand-new createAccountsRouter() at /accounts, with its own GET /:address/summary reading from a materialized AccountSummary table and returning { address, assets: [...] }.

Your PR also adds a route handler at /accounts/:address/summary that re-uses the old summaryHandler (which reads from TokenTransfer directly and returns { address, tokens: [...] }).

Two endpoints, same path, different response shapes, different data sources. Whichever is registered first in createApp() wins — and your integration test:

const body = await getJson(`/accounts/${ALICE}/summary`);
expect(body.tokens).toEqual([…]);

is hard-coded to the legacy { tokens: [...] } shape and would silently fail (or worse, fail intermittently depending on createApp route ordering) once both handlers are in the same binary.

Cleanest fix — drop the alias from this PR and point the test at the still-supported legacy URL:

- app.get("/summary/:address", summaryHandler);
- app.get("/accounts/:address/summary", summaryHandler);
+ app.get("/summary/:address", summaryHandler);

and in tests/integration/api.test.ts:

- const body = await getJson(`/accounts/${ALICE}/summary`);
+ const body = await getJson(`/summary/${ALICE}`);

That way #89's materialized endpoint owns /accounts/:address/summary (with the new shape and AccountSummary reads), and the legacy aggregator-on-the-fly stays available at /summary/:address for your harness.

2. Dockerfile regression

- RUN npm ci --omit=dev
+ RUN npm ci
…
- CMD ["sh", "-c", "npx prisma migrate deploy && node dist/index.js"]
+ CMD ["node", "dist/index.js"]

This balloons the production image with every devDependency (typescript, ts-node-dev, @types/*, vitest after this PR, etc.) and removes the migration step from container start. The comment claims "the app runs Prisma schema sync on startup" — does it actually? I don't see a prisma db push or prisma migrate deploy call in src/index.ts on main. If migrations aren't applied at app start, the runtime image will hit relation does not exist on a clean DB.

Two options:

• Best: keep the production Dockerfile exactly as it is on main, and add a separate Dockerfile.test referenced from docker-compose.test.yml. Dockerfile.test can npm ci (no --omit=dev) freely without affecting prod image size.
• Acceptable: keep one Dockerfile but use a multi-stage layout — final stage stays --omit=dev, and a separate test stage includes Prisma CLI for tests. Production CMD keeps migrate deploy.

Once those two are sorted I'll merge — the rest of the PR is good and #63 closes cleanly.