Supabase Postgres replaced with Aurora Serverless v2 via RDS Data API

The CDK shape is straightforward: a DatabaseStack adds an Aurora Serverless v2 PostgreSQL 16 cluster (bumped to 17.9 later in 1b2f80d) with enableDataApi: true, isolated VPC subnets, and no VPC NAT gateways. The Lambda execution role gets rds-data:ExecuteStatement and related actions on the cluster ARN, plus secretsmanager:GetSecretValue for the cluster's auto-generated secret. A db.ts wrapper (d90454b) handles parameter building and result parsing uniformly across routes.

Route migration proceeds file by file across about fifteen commits. The pattern is the same in each: swap the Supabase client for execute() / queryOne() / query() calls, rewrite the SQL to named parameters with :paramName syntax, and handle the Aurora Data API's quirk of returning jsonb columns as raw strings (requiring JSON.parse on read). The shared_with and columns_config columns hit this issue in multiple places and required separate fix commits.

Two specific fixes are non-optional if you take this route. The auto-UUID-typeHint wrapper (2daea68) inspects parameter names and automatically applies typeHint: 'UUID' for anything named id, *Id, or *_id. Without it, Aurora throws uuid = text type errors that don't appear in development but fail in production. The auto-pause retry (f49ac20) wraps db.ts with exponential backoff for the BadRequestException: Communications link failure that Aurora Serverless throws on cold start when serverlessV2MinCapacity: 0. Both fixes arrived after the main migration - the initial commits didn't have them.

The projectChat.ts route and chat_messages table are deleted (b035d67, c195e91) because AgentCore's S3 conversation state replaces relational message storage. Importing this migration without that companion means you'll have dead schema and dead routes.