Evaluate node-postgres for production Neon connections

[dcramer]

Junior currently defaults to @neondatabase/serverless for production database access on Vercel. Evaluate switching production usage to the existing node-postgres driver so we can use maintained pg-based Sentry/OpenTelemetry query instrumentation without custom Neon driver instrumentation.

Evaluate in staging with:

• Neon’s pooled connection string
• one process-level pg.Pool with a low connection limit
• Vercel attachDatabasePool(pool) lifecycle management
• Sentry initialized before pg is imported
• the existing JUNIOR_DATABASE_DRIVER=postgres path

Compare:

• cold and warm query latency
• open and peak database connection counts
• transaction and advisory-lock behavior
• serverless suspension/resume behavior
• Sentry database span coverage and query-duration visibility

Acceptance criteria:

• document the staging measurements and connection behavior
• decide whether to keep the Neon serverless driver or switch production to node-postgres
• define a safe rollout and rollback plan if switching
• do not add custom Neon query/OpenTelemetry instrumentation