Nothing applies a migration, so a schema change is an outage #277

Background

This repo commits its migrations — there are nine under prisma/migrations/ —
and nothing runs them. build is tsc, start is node dist/index.js.

So a PR that adds a column and its migration still leaves the column missing in
production until somebody runs it by hand. On the offramp that is worse than a
plain failure: createOfframpOrder calls Linq before writing our row, so a
failed insert leaves a real provider payout order with no record of ours.

This nearly happened: PR #210 added requestHash with no migration at all.

What to build

• Apply migrations as part of starting or deploying, or fail loudly when the
  database is behind what the code expects. Either is defensible; silently
  running against an older schema is not.
• Be careful with prisma migrate deploy here: past use of prisma db push
  means _prisma_migrations may not record migrations that are in fact
  applied, so a naive deploy may try to recreate existing objects. Investigate
  the real state before choosing, and write down what you found.

Acceptance criteria

• A schema newer than the database is detected, not ignored
• The chosen mechanism is documented, including why
• The _prisma_migrations state is checked and the finding recorded
• Nothing drops or rewrites an existing table

Drips Wave · Complexity: Intermediate · 150 points

Repo: Miracle656/wraith (Express + TypeScript + Prisma). Run npm test
(jest) and npm run typecheck. Both must pass.

This service moves real money, and Linq has no sandbox. Every /ngn and
/offramp route is mainnet-gated at the router for that reason. Test against
the fake provider in src/__tests__, never against Linq. A single careless
integration test spends somebody's naira.

The provider rate limit is shared and real. All Veil users share one Linq
key. Four manual probes of /ngn/onramp/rate returned 429 rate_limited
during a review. Do not poll the live provider while developing.

A NIN is personal data under Nigeria's NDPA. It must never be stored,
logged, or placed in a test fixture. The existing KYC fixtures contain error
codes and messages only — keep it that way.

Metrics labels must be bounded. Label by things drawn from a finite set:
rail, route, outcome, network, provider error code. Never by an order id, a
customer reference, an amount, a URL or a raw provider message. An unbounded
label makes /metrics grow until it cannot be scraped.

A schema change needs a migration. This repo commits migrations under
prisma/migrations/, and neither build nor start applies one. A
schema.prisma change merged without a migration file means the column never
exists in production. After changing the schema run npx prisma generate
before typecheck, or you will chase errors that are not real.

Never elide an address, a contract id or a key in code, comments or test
fixtures. A previous batch shortened a contract id in an issue text and five
contributors invented their own to fill the gap.

Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk