feat(deploy): a serverless entry, and migrations as a deploy step

[fajarhide]

Three changes that stand between the gateway and a serverless deploy.

api/index.ts builds the pool and the provider registry at module scope, so they
survive between invocations, and exports the Express app createServer already
returns. vercel.json routes every path to it and runs npm run migrate at build.

Migrations no longer happen at cold start. scripts/migrate.ts reads only
DATABASE_URL, deliberately not loadConfig, so the deploy step never carries
VAULT_KEY for work that does not use it. main.ts keeps its boot migration for
self-host, where one process starts once and owns the database.

DATABASE_POOL_MAX makes the pool size an env var. Ten connections per instance is
right for one long lived server and wrong when every instance opens its own pool
against a shared ceiling.

Verified against a real Postgres:

$ DATABASE_URL=...selat_migrate_probe npm run migrate
{"msg":"migrated"}                       # 11 tables in an empty database
$ DATABASE_URL=...selat_migrate_probe npm run migrate
{"msg":"migrated"}                       # idempotent

$ node --experimental-strip-types boot-api.ts
ready: 200 {"status":"ready"}             # the api entry booted and answered

$ npm test
Test Files  36 passed (36)
Tests  366 passed (366)

Still needed before this is live, and none of it belongs in the repo: a pooled
DATABASE_URL, the environment set on Vercel, and a second GitHub OAuth App for
production, since a GitHub OAuth App takes only one callback URL.

[fajarhide]

Superseded by the trimmed version. The gateway runs beside its Postgres rather than on Vercel, so the entry point and vercel.json here would be a deploy target nobody runs and nothing tests. Only DATABASE_POOL_MAX survives.