feat: add database migration tooling

[Keengfk]

Summary

Sets up Prisma as the schema migration layer for vortex-backend, addressing the
requirement from #36 to version schema changes rather than applying them ad
hoc. The service still uses in-memory stores for all feature data — this PR
lays the foundation so the on-chain writes roadmap item can swap them out for
real DB-backed services without a separate tooling setup step.

───────────────────────────────────────────────────────────────────────────────

Changes

Schema & migrations

• prisma/schema.prisma — three models (Intent, Solver, Token) with IntentState
  and SupportedChain enums, JSONB columns for nested token objects, and indexes
  on all commonly-filtered fields (user, state, solver, chain, symbol)
• prisma/migrations/20240101000000_init/migration.sql — initial DDL checked
  into version control so every developer and CI run starts from the same
  baseline

NestJS integration

• src/prisma/prisma.service.ts — extends PrismaClient, connects on
  onModuleInit, disconnects on onModuleDestroy
• src/prisma/prisma.module.ts — @global() module imported once in AppModule;
  any feature module can inject PrismaService without re-importing

Configuration

• DATABASE_URL added to Joi validation schema (with a safe default so the app
  boots without a live DB in unit tests), AppConfig interface, and .env.example

npm scripts

┌────────┬──────────────┐
│ Script │ What it does │
├─────────────────────┼─────────────────────────────────────────────┤
│ npm run db:generate │ Regenerate Prisma client after schema edits │
├─────────────────────────┼─────────────────────────────────────────────┤
│ npm run db:migrate │ Create a new migration (dev) │
├─────────────────────────┼─────────────────────────────────────────────┤
│ npm run db:migrate:prod │ Apply pending migrations (production / CI) │
├─────────────────────────┼─────────────────────────────────────────────┤
│ npm run db:studio │ Open Prisma Studio │
├─────────────────────────┼─────────────────────────────────────────────┤
│ npm run db:validate │ Validate schema without a DB connection │
└─────────────────────────┴─────────────────────────────────────────────┘

Docker

• Build stage runs db:generate so the image ships with a pre-built client
• Runtime CMD runs prisma migrate deploy && node dist/main.js — migrations are
  applied automatically on every container start, making it impossible to forget
  the step

CI

• postgres:16-alpine service container added to the backend job
• Migration steps (db:validate → db:generate → db:migrate:prod) run before
  lint/typecheck/build/test, catching broken migration SQL before merge

───────────────────────────────────────────────────────────────────────────────

Testing

• Added src/prisma/prisma.service.spec.ts (unit test — mocked
  $connect/$disconnect, lifecycle hooks, model accessor shape)
• Updated test/utils/create-test-app.ts to override PrismaService with a no-op
  mock so e2e suites remain self-contained (no live database required to run npm
  run test:e2e)

npm run lint ✓ 0 errors
npm run typecheck ✓ 0 errors
npm run build ✓ clean
npm test ✓ 22 tests, 4 suites
npm run test:e2e ✓ 23 tests, 5 suites
prisma validate ✓ schema valid

closes #57

[drips-wave]

@Keengfk 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