Neon on Vercel Edge: use the HTTP one-shot client, never a pooled Pool

# Neon on Vercel Edge: use the HTTP one-shot client

## The trap
Vercel Edge Functions have no TCP sockets. If you point node-postgres (or any TCP Postgres client) at Neon from the Edge runtime, the connection just fails. And if you create a `Pool` from `@neondatabase/serverless` at module scope, the WebSocket behind it cannot outlive the request, so you get flaky hangs and leaked connections.

## The rule
On Edge, query over HTTP with the `neon()` one-shot client. It is built for exactly this: single non-interactive queries and non-interactive multi-statement transactions over fetch.

```ts
import { neon } from '@neondatabase/serverless';
const sql = neon(process.env.DATABASE_URL);
const posts = await sql`SELECT * FROM posts WHERE id = ${postId}`;
```

## If you must use Pool or Client on Edge
Neon's docs are explicit: in serverless environments like Vercel Edge Functions or Cloudflare Workers, WebSocket connections cannot outlive a single request. So the Pool or Client must be connected, used, and closed inside one request handler. Never create it at module scope and reuse it across requests.

```ts
import { Pool } from '@neondatabase/serverless';
export async function GET() {
  const pool = new Pool({ connectionString: process.env.DATABASE_URL });
  try {
    const { rows } = await pool.query('SELECT * FROM posts');
    return Response.json(rows);
  } finally {
    await pool.end();
  }
}
```

## Checklist
- Edge runtime -> `neon()` HTTP client, not `pg`, not a shared Pool.
- Node runtime (Vercel Serverless Functions) -> either the serverless driver over WebSockets or a normal pooled connection string.
- Interactive transactions (BEGIN/COMMIT across awaits) need WebSockets, not HTTP.
- Verify by deploying: a module-scope Pool on Edge fails or hangs on the second request; the per-handler pattern stays clean.